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EXECUTIVE  SUMMARY 


The  Airport  and  Airspace  Delay  Model  (AADM) ,  newly  developed  by 
SRI  International  for  the  Federal  Aviation  Administration,  is  an  event- 
step  simulation  written  in  the  high-level  SIMSCRIPT  II. 5  programming 
language  that  traces  the  movement  of  individual  aircraft  through  a  link 
and  node  route  network.  AADM  is  designed  to  simulate  the  real-world 
processes  by  which  aircraft  fly  through  air-traffic-controlled  enroute 
and  terminal  airspace  and  arrive  and  depart  through  airport  runway  complexes. 
AADM  is  capable  of  modeling: 

•  Airspace  route  structures  and  runway  configurations 

•  Airspace  and  airport  separation  and  related  operating  procedures 

•  Multiple  airports 

•  Multiple  control  sectors 

•  VFR  vs  IFR  procedures  and  visibility  conditions 

•  Terminal  routing  plan  changes 

•  Route  restrictions 

•  Sector  capacities 

•  Wind  conditions 

•  Aircraft  characteristics  (e.g.,  type  and  speed). 

The  AADM  modeling  outputs  include  delay  and  travel  time  statistics 
and  a  log  of  all  simulation  events. 

The  AADM  program  includes  two  basic  components: 

•  Airspace  traffic  control  logic 

•  Airport/airspace  interface  logic. 

The  airspace  traffic  control  logic  simulates  three  levels  of  the  ATC 
operational  process:  Level  I — tactical  control;  Level  II — sequencing  control; 
Level  III — strategic  control.  The  Level  I  logic  simulates  the  processes 
by  which  controllers  maintain  minute-by-minute  separation  between  aircraft 
pairs  by  vectoring  and  path  stretching,  speeding  up  or  slowing  down,  or 
holding  aircraft.  The  Level  II  logic  simulates  the  processes  by  which 


controllers  coordinate  their  near-term  separation  service  plans  and 
sequence  and  space  aircraft  for  downstream  merges.  The  Level  III  logic 
simulates  the  processes  by  which  controllers  coordinate  their  multisector 
procedural  rules  (e.g.,  in-trail  spacing  adjustments  at  facility  boundaries) 
and  meter  aircraft  into,  out  of,  and  through  the  airspace  network,  to  balance 
traffic  flows. 

The  airport/airspace  interface  logic  simulates  three  runway-system- 
dependent  components  of  ATC  operations:  final  approach  control,  takeoff/ 
landing  control,  and  departure  control.  The  final  approach  logic  simulates 
the  fine  tuning  of  separations  (largely  by  speed  control)  along  the  approach 
courses  to  runways  and  allows  for  VFR  pairwise  side-by  operations  and  IFR 
in-trail  separation  requirements.  The  takeoff /landing  logic  simulates  the 
specific  separation  procedures  for  a  selected  runway  system  that 
allow  interleaving  of  crossing,  same-direction,  or  parallel  arrival  and 
departure  operations.  The  departure  logic  simulates  the  control  procedures 
by  which  successive  departures  take  off  from  identical,  crossing,  or 
parallel  runways  (provided  that  landing  operations  do  not  interfere)  by 
taking  into  account  runway  occupancy  times,  runway  exit  and  intersection 
locations,  airspace  spacing  requirements,  and  special  route  restrictions. 

The  Oakland  Bay  TRACON's  airspace  was  used  to  demonstrate  an 
application  of  AADM.  This  airspace  has  a  rather  complex  route  structure 
mainly  serving  airports  at  San  Francisco,  Oakland,  and  San  Jose.  AADM 
simulated  the  major  elements  of  this  airspace  and  the  three-airport  opera¬ 
tion  using  routing,  traffic  loading,  and  control  procedures  data  collected 
from  the  local  ATC  facilities. 
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I  INTRODUCTION 


The  Airport /Airspace  Delay  Model  (AADM)  is  an  event  step  computer 
simulation  program  that  quantitatively  estimates  aircraft  travel  time  and 
delay.  The  model,  which  is  written  in  the  SIMSCRIPT  II. 5  programming 
language,  can  be  used  to  simulate  both  enroute  airspace  and  terminal 
airspace  with  multiple  airports.  AADM  replicates  airspace  route  structures 
and  runway  configurations  (exclusive  of  taxiways  and  aprons)  and  models 
such  operational  elements  as  separation  procedures,  air  traffic  flight 
patterns  and  traffic  loadings,  runway  occupancy,  aircraft  overtakes,  path 
crossing,  holding  at  navigational  fixes,  airspace  sectorization ,  sector 
workload  constraints,  and  aircraft  delays  due  to  speed  changes,  holding, 
and  vectoring.  The  program  can  simulate  changes  to  wind,  visibility 
conditions,  and  runway  and  airspace  routine  plans  so  that  the  user  may 
examine  particular  situations  and  assess  delay  implications. 

The  simulation  tracks  individual  aircraft  on  predefined  routes. 

During  the  course  of  a  simulation  an  aircraft  moves  along  a  series  of 
airspace  links  from  node  to  node.  All  aircraft  are  injected  into  the 
modeled  airspace  system  at  either  an  airport  runway  or  a  boundary  node. 
Similarly,  each  route  terminates  at  an  airport  runway  or  a  boundary  node. 
Thus,  the  user  may  simulate  aircraft  arriving  in  the  terminal  enroute 
airspace  and  landing  at  an  airport,  aircraft  taking  off  from  an  airport 
and  departing  the  airspace,  aircraft  taking  off  from  an  airport  and  landing 
at  another  airport  in  the  modeled  airspace,  and  aircraft  transiting  the 
airspace.  An  airport  runway  configuration  (including  exits  and  crossings) 
is  modeled  in  sufficient  detail  to  simulate  arrivals,  runway  occupancy 
time,  and  sequencing  of  departures  and  arrivals.  The  rates  at  which 
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aircraft  enter  each  route  of  the  airport  and  airspace  system  are  determined 
by  user  specified  program  parameters  which  enable  traffic  demand  to  change 
with  time. 

In  order  to  facilitate  simulation  of  two  distinct  air  traffic  operational 
environments — the  airspace  and  airport  systems — the  AADM  program  includes 
two  interrelated  components : 

•  Airspace  traffic  control  logic 

•  Airport/airspace  interface  logic. 

This  software  structure  enables  separate  development  and  refinement  of 
the  programming  logic  appropriate  to  each  component  and  allows  for  the 
establishment  of  logic  linkages  between  the  two;  other  programming  components 
conduct  data  input,  output,  and  model  supervision  processes.  The  airspace 
traffic  control  logic  simulates  the  control  processes  by  which  controllers 
maintain  pairwise  aircraft  separations,  sequence  and  space  aircraft  for 
downstream  merging,  and  regulate  areawide  traffic  flows.  The  airport/airspace 
interface  logic  simulates  the  processes  by  which  aircraft  transition  between 
the  airspace  and  airport  runway  environments  and  move  through  runway  systems. 

The  AADM  is  structured  to  allow  modular  operation  of  the  two  components, 
should  the  need  arise.  This  capability  enables  modeling  of  airspace  regions 
which  do  not  interface  with  airports  as  well  as  the  modeling  of  runway 
systems  and  their  final  approach  and  departure  airspaces.  An  overview  of  the 
modeling  features  of  the  two  logic  components  is  given  in  the  remainder  of 
this  section. 

A.  Airspace  Traffic  Control  Logic  Overview 

AADM  simulates  the  movement  of  aircraft  through  an  airspace  system 
by  modeling  each  aircraft's  flight  path  and  speed  preferences  and  by 
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modeling  che  various  air  traffic  control  (ATC)  actions  used  to  expedite 
traffic  flow  and  maintain  aircraft  separations.  These  control  actions 
range  from  the  detailed  monitoring  and  adjustment  of  individual  aircraft 
trajectories  to  the  setting  of  overall  procedural  constraints  and  guide¬ 
lines  for  the  use  of  the  airspace  and  airport  runway  systems.  In  order 
to  realistically  simulate  the  intrinsically  complex  nature  of  ATC  operations, 
the  airspace  traffic  control  logic  is  structured  according  to  a  multilevel 
interactive  hierarchical  decomposition  concept  consisting  of: 

•  Level  I — Tactical  Control 

•  Level  II— Sequencing  Control 

•  Level  III — Strategic  Control. 

This  three-level  programming  framework  is  used  to  represent  as  closely 
as  possible  the  actual  control  procedures  observed  and  studied  by  SRI,  and 
is  applicable  to  both  enroute  and  terminal  operations. 

1 .  Level  I — Tactical  Control 

At  the  tactical  Level  I,  the  AADM  program  provides  a  detailed,  event- 
step,  aircraft-following  simulation  of  the  movement  of  aircraft  through  the 
airspace  route  structure.  As  individual  aircraft  are  tracked  through  the 


route  network,  specific  events  (e.g.,  crossing  and  merging  conflicts)  are 
generated  which  require  control  actions  to  ensure  that  safe  separation  and 


operating  standards  are  met.  The  control  actions,  which  include  vectoring 
and  path  stretching,  speeding  up  or  slowing  down,  or  holding  maneuvers  to 
resolve  situations,  are  modeled  by  Level  I.  The  Level  I  logic  is  used  to 
model  such  situations  as  those  that  entail  conflict  resolutions,  sector 
workload  constraints,  and  terminal  traffic  plan  changes. 

Conflict  Resolution — The  Level  I  conflict  resolution  process  can  be 


explained  with  the  aid  of  Figure  1,  which  shows  a  subset  of  the  links  and 
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nodes  used  to  represent  an  airspace  network.  Each  link  represents  a  unique 
flight  path  joining  two  points  in  three  dimensional  space,  with  each  such 
point  represented  by  a  node.  The  Level  I  software  moves  aircraft  from  one 
node  to  the  next  along  a  directed  link  and  adjusts  the  motion  of  aircraft 
to  guarantee  proper  separation  at  each  node  and  thereby  resolve  potential 
crossing,  merging,  or  overtaking  conflict.  In  Figure  1,  aircraft  on  links 
1  and  2  are  adjusted  (by  speed  or  vectoring  control)  or  held  at  nodes  A 
or  B  to  prevent  merging  conflicts  at  the  downstream  node  C.  In  parallel 
with  the  tracking  of  aircraft  approach  node  C,  the  Level  I  logic  will  monitor 
aircraft  along  link  3  to  ensure  proper  separation  at  node  D. 

Subroutines  within  Level  I  enable  a  variety  of  control  actions  con¬ 
sistent  with  the  specification  of  the  airspace  operation  being  modeled. 

Such  specifications,  which  are  defined  during  data  input,  describe  the 
types  of  operations  that  are  permitted  along  each  link  (e.g.,  whether  or  not 
overtaking  is  allowed,  or  whether  speed  or  vectoring  control  is  preferred), 
the  operating  environment  (e.g.,  link  heading,  distance,  wind  vector, 
aircraft  capacity,  and  visibility  conditions,  as  well  as  node  altitude,  air¬ 
craft  holding  capacity,  and  separation  rules  in  effect),  and  aircraft  charac¬ 
teristics  (e.g.,  aircraft  type,  planned  flight  speed,  range  of  permissible 
speed  change,  and  planned  route  profile).  The  Level  I  logic  selects  the 
intervention  tactics  representative  of  the  actions  taken  by  controllers  as 
they  continually  monitor  aircraft  on  a  minute-by-minute  basis  and  tabulates 
travel  time  and  delay  (positive  or  negative)  data. 

Sector  Workload  Constraints — The  Level  I  logic  tracks  the  movement  of 
aircraft  through  each  ATC  sector  to  check  for  and  prevent  traffic  loading 
situations  that  would  violate  sector  workload  constraints.  Each  sector  is 
identified  in  AADM  by  a  unique  set  of  links  that  make  up  its  airspace. 
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The  AADM  user  may  specify  a  workload  constraint  represented  by  a  maximum 
number  of  aircraft  for  each  sector.  If  an  aircraft  attempts  to  enter  a 
link  in  a  workload  saturated  sector,  the  program  will  hold  that  aircraft 
at  its  current  node  until  the  downstream  sector  becomes  unsaturated  and 
will  update  the  travel  time  and  delay  tabulations. 

Terminal  Traffic  Plan  Changes — Terminal  airspace  approach  and  departure 
routings  depend  in  part  on  airport  locations,  local  terrain,  runway  con¬ 
figuration,  and  meteorological  situations.  Changes  to  these  situations — 
especially  wind  speed  and  direction  and  runway  closures—trigger 
revisions  to  the  terminal  traffic  plan  in  effect.  Typically,  a  significant 
change  in  wind  will  cause  a  plan  "turnaround"  in  which  new  approach  and  depar¬ 
ture  routings  are  implemented  with  allowances  for  transitioning  from  the 
old  to  the  new  plan.  The  AADM  simulates  such  plan  changes  at  any  point 
during  a  model  run  and  employs  portions  of  the  Level  I  logic  to  carry  out 
the  transition  from  one  plan  to  another.  This  logic  ensures  that  proper 
separations  are  maintained  when  aircraft  alter  their  routings.  The  AADM 
plan  change  logic,  which  involves  Levels  II  and  III  as  well  as  Level  I, 
enables  simulation  of  transitions  between  IFR  and  VFR  operations. 

2.  Level  II — Sequencing  Control 

The  Level  II  logic  models  the  processes  by  which  controllers  "look¬ 
ahead"  along  the  route  structure  network  and  coordinate  the  movement  of 
individual  aircraft  in  anticipation  of  specific  downstream  operational 
requirements.  Such  actions  are  aimed  at  expediting  the  movement  of  traffic 
and  preventing  congestion  problems  from  developing  which  cannot  be  reasonably 
handled  at  the  tactical  level.  The  primary  use  of  the  Level  II  logic  is 
to  simulate  the  sequencing  and  spacing  of  aircraft  fob  downstream  merges. 
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Figure  2  shows  a  link  and  node  representation  of  a  hypothetical  route 
network  serving  approach  traffic  to  two  airports.  The  approach  fix  for 
one  airport  is  at  node  X  and  aircraft  approaching  this  airport  enter  the  route 
system  at  boundary  nodes  A,  B,  C,  D,  E  and  F.  The  Level  II  logic  ”sets-up" 
all  aircraft  destined  to  merge  at  the  approach  fix  node  X  by  initiating 
sequencing  and  spacing  control  actions  when  the  aircraft  enter  the  route 
system  at  the  boundary  nodes.  For  example,  an  aircraft  on  link  1  and  one  on 
link  3  (which  could  be  in  two  different  sectors)  would  be  maneuvered  by 
the  Level  II  logic  so  that  they  would  be  properly  spaced  for  sequencing  on 
to  the  final  approach  course  at  node  X.  The  spacing  adjustments  would 
be  in  conformance  with  the  separation  rules  in  effect  at  node  X,  would 
involve  vectoring  and  path  stretching,  speed  control  or  holding  actions,  and 
would  be  performed  repeatedly  as  aircraft  move  from  link  to  link  toward 
the  approach  fix. 

The  sequencing  logic  is  carried  out  within  the  constraints  permitted 
by  the  Level  I  tactical  control  logic  which  is  operating  in  parallel  to 
Level  II.  For  example.  Level  I  will  ensure  that  proper  spacing  is 
effected  at  node  G  for  each  aircraft  on  links  1  and  2,  while  Level  II  will 
sequence  these  aircraft  with  each  other  and  with  all  other  aircraft  on  links 
of  routes  merging  at  the  approach  fix  node  X.  The  AADM  program  will  update 
the  aircraft  travel  time  and  delay  tabulations  in  accordance  with  the 
simulated  control  actions. 

The  Level  II  logic  is  designed  to  coordinate  aircraft  movement  in  a 
multiple-airport  environment  by  sequencing  aircraft  to  selected  merge  points. 
As  shown  in  Figure  2,  aircraft  passing  through  boundary  nodes  may  be 
sequenced  to  either  approach  fix  node  X  or  node  Y  depending  on  which  of  the 

7 


1 


U- 


two  airports  are  the  destination.  However,  the  Level  II  logic  is  not 
constrained  to  simulating  only  airport  merging  operations;  any 
airspace  merging  situation  can  be  simulated  by  designating  an  appropriate 
Level  II  merge  or  "post"  node  and  corresponding  Level  II  "feeding"  or 
"metering"  nodes.  Also,  Level  II  post  And  metering  nodes  must  be  specifi¬ 
cally  defined  for  each  terminal  traffic  plan  under  study  so  as  to  distinguish 
the  sequencing  procedures  appropriate  to  each  plan. 

3.  Level  III — Strategic  Control 

The  Level  III  logic  simulates  the  processes  by  which  controllers 
coordinate  and  implement  systemwide  procedural  rules  and  regulate  or  meter 
traffic  through  their  airspace.  Such  actions  balance  traffic  flows  through 
the  overall  route  network  by  setting  flow  constraints  compatible  with  down¬ 
stream  acceptance  rates.  The  primary  use  of  Level  III  is  to  determine 
separation  rules  for  key  network  control  points — especially  facility 
boundaries — so  that  traffic  is  fed  at  realistic  rates  into  the  tactical 
and  sequencing  control  environment.  In  effect,  the  Level  III  strategic  con¬ 
trol  logic  serves  as  a  traffic  modulator  which  ensures  that  aircraft 
concentrations  do  not  occur  that  would  overpower  the  capabilities  of  the 
Level  I  and  II  operations  to  move  traffic. 

The  link  and  node  network  shown  in  Figure  2  is  shown  again  in  Figure 
3,  but  with  a  hypothetical  TRACON  facility  boundary  designated  through 
nodes  A,  B,  C,  D,  E,  and  F.  For  the  purpose  of  the  Level  III  logic,  nodes 
X  and  Y  are  designated  as  post  nodes  for  traffic  entering  the  final  approaches 
on  links  from  the  Level  III  boundary  nodes.  The  Level  III  logic  meters 
traffic  through  each  boundary  node  by  specifying  in-trial  spacing  rules 
(e.g.,  5,  10,  or  IS  nautical  miles)  that  are  compatible  with  the  separation 
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and  traffic  loading  requirements  of  post  nodes  X  and  Y.  This  process 
balances  the  flow  rate  through  each  boundary  node  to  match  the  acceptance 
rate  of  the  final  approach  post  nodes  and  is  based  in  part  on  the  projec¬ 
tion  of  pending  arrivals  during  successive  user-specified  time  intervals 
(e.g.,  1,  2,  5,  or  10  minutes). 

The  Level  III  logic  responds  to  time-changing  variances  in  traffic 
loadings  along  each  route.  In  Figure  3,  a  heavy  traffic  loading  is  indi¬ 
cated  along  the  route  through  node  C  to  post  node  X  and  less  intense 
traffic  loadings  are  indicated  on  the  other  inbound  routes.  Level  III  will 
calculate  the  in-trail  spacing  rules  for  each  boundary  node  for  an  upcoming 
time  interval  so  as  to  expedite  flow  along  the  heavily  loaded  route.  This 
process  is  dynamically  self-adjusting  in  that  the  Level  III  logic  will 
recalculate  spacing  requirements  for  successive  time  intervals  during  the 
course  of  the  simulation  and  thereby  react  to  changing  traffic  demand 
circumstances . 

The  Level  III  post  and  metering  nodes  need  net  be  identical  to  the 
Level  II  post  and  metering  nodes,  but  as  in  the  case  of  the  Level  II 
operation,  all  post  and  metering  nodes  applicable  to  different  terminal 
traffic  plans  must  be  specifically  defined  for  each  plan. 

B.  Airport/Airspace  Interface  Logic  Overview 

The  AADM  program  enables  modeling  of  traffic  operations  for  each 
of  the  airport  runway  systems  under  study  and  provides  for  interfacing 
each  such  runway  system  model  with  its  counterpart  model  of  airspace  traffic 
control.  The  airport /airspace  interface  software  simulates  the  control 
actions  placed  on  aircraft  while  executing  approach  and  departure  operations 
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through  the  runway  system  and  adjacent  airspace,  and  consists  of  three 
subcomponents  that  model  travel  time  and  delay  impacts  associated  with: 

•  Final  approach  control 

•  Takeoff /landing  control 

•  Departure  control. 

The  three  subcomponents  are  interactively  linked  to  ensure  that  all 
aspects  of  airport-related  traffic  movement  are  properly  integrated  in 
the  AADK  program.  The  airport/airspace  interface  logic  may  be  used  to 
simultaneously  model  any  number  of  airports  using  input  data  that  separately 
describe  each  airport.  Such  data  as  runway  occupancy  times,  separation 

rules,  and  runway  utilization  procedural  descriptions  must  be  defined  for 
each  airport  as  appropriate  for  each  terminal  traffic  plan  under  study. 

1 .  Final  Approach  Control 

The  final  approach  control  logic  simulates  the  processes  by  which 
controllers  setup,  monitor,  and  fine-tune  the  spacing  of  aircraft  along 
the  final  approaches  to  a  runway  system.  This  logic  is  applicable  to 
single  runway  operations  or  more  complex  ones  such  as  the  closely-spaced 
parallel  runway  pair  shown  in  Figure  4.  Nodes  1  and  2  represent  the  runway 
landing  thresholds  and  nodes  3  and  4  represent  the  fix  at  which  aircraft 
initiate  final  approach  to  their  respective  runways. 

Under  VFR  operating  rules,  pairwise  operations  are  permitted  in  which 
two  aircraft  may  approach  in  a  side-by  configuration  so  long  as  suitable 
separation  is  maintained  between  preceding  and  following  aircraft.  Such 
side-by  operations  are  useful  in  busy  runway  situations  where  crossing  departures 
are  interleaved  between  suitably  spaced  arrival  pairs.  Controllers  setup 
the  VFR  operation  by  coordinating  the  turning  of  aircraft  through  approach 
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FINAL  APPROACH  CONTROL — VFR 


fix  so  that  side-by  or  near-side-by  situations  exist.  Controllers 
then  monitor  the  final  approach  and  endeavor  to  maintain  the  side-by 
configuration  and  spacing  (usually  by  speed  control  instructions)  although 
pilots  have  considerable  influence  over  the  actual  flight  pattern  flown 
under  visual  conditions. 

The  AADN  final  approach  logic  is  designed  to  model  the  above  described 
VFR  operation  where  such  procedures  are  in  effect.  Program  algorithms — 
which  are  actually  imbedded  in  the  Level  I  airspace  traffic  control  logic, 
but  can  be  operated  independently  of  the  airspace  model — simulate  the 
setting-up  maneuvers  (e.g.  ,  speed  control,  vectoring)  required  for  pairwise 
coupling  as  the  aircraft  converge  on  the  approach  fixes,  and  simulate 
their  movement  along  final  approach.  The  program  enables  the  modeling 
of  variations  from  the  strict  side-by  configuration  by  permitting  aircraft 
in  a  couple  to  deviate  logitudinallv  from  their  intended  position 
(e.g.,  one  aircraft  in  a  side-by  pair  may  be  allowed  to  position  itself 
some  distance — such  as  one  mile — ahead  of  or  behind  the  other  aircraft). 

The  final  approach  logic  also  ensures  that  landing  runway  operating  rules 
are  not  violated  by  checking  data  describing  runway  occupancy  times 
for  specific  aircraft  types  and  exit  distances. 

The  corresponding  IFR  operation,  as  illustrated  in  Figure  5  for  the 
closely-spaced  parallels,  does  not  permit  simultaneous  side-by  approaches. 
The  final  approach  logic  handles  this  situation  by  ensuring  proper  separa¬ 
tion  (e.g.,  3  nautical  miles  or  more  for  wake  turbulence)  between  each 
successive  aircraft  regardless  of  approach  course  and  simulates  the 
setting-up  of  IFR  spacing  as  aircraft  converge  on  the  approach  fixes. 
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2 .  Takeoff/Landing  Control 

In  many  operating  situations,  the  geometry  of  the  runway  configura¬ 
tion  requires  that  a  high  degree  of  coordination  be  effected  between  takeoff 
and  landing  maneuvers  to  maximize  runway  utilization.  Typically,  takeoffs 
and  landings  are  interleaved  with  each  other  subject  to  the  constraints 
of  the  separations  required  for  arrival  aircraft.  The  AADM  takeoff /landing 
control  logic  simulates  the  process  by  which  departing  aircraft  are  inter¬ 
leaved  between  arrivals. 

Figure  6  shows  a  runway  configuration  consisting  of  two  pairs  of 
crossing  parallels.  An  aircraft  waiting  at  a  departure  runway  threshold  will 
not  be  cleared  for  takeoff  if  its  runway  is  "blocked"  by  an  arriving  aircraft 
using  a  crossing  runway.  In  the  Figure  6  example,  such  blockage  occurs  when  a 
landing  aircraft  is  between  a  check  point  2  nautical  miles  from  the  arrival 
runway  threshold  and  the  intersection  of  the  arrival  and  departure  runways; 
the  blockage  ends  when  the  intersection  is  cleared.  The  takeoff /landing 
logic  checks  the  location  of  landing  aircraft  (for  both  arrival  runways)  to 
determine  whether  a  pending  departure  needs  to  be  delayed  until  suitable 
separation  situations  occur.  The  takeoff /landing  control  logic  of  AADM 
may  be  applied  to  any  runway  configuration. 

3.  Departure  Control 

In  addition  to  satisfying  separation  rules  associated  with  arrival 
interactions,  departure  operations  must  also  conform  to  separations  require¬ 
ments  for  successive  departures.  The  AADM  departure  control  logic  performs 
the  final  check  required  before  an  aircraft  takeoff  operation  can  be 
initiated  in  the  simulation. 
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FIGURE  6.  TAKEOFF /LANDING  CONTROL 
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Figure  7  demonstrates  the  types  of  control  complexities  involved  for  a 
pair  of  closely-spaced  parallel  departure  runways.  In  this  case,  the 
issuance  of  departure  release  is  subject  to  the  satisfaction  of  various 
criteria  describing  runway  occupancy  and  airspace  spacing  constraints. 

The  spacing  rules  vary  according  to  whether  successive  aircraft  are 
diverging  or  following  each  other,  whether  at  least  one  aircraft  is  heavy, 
which  runways  are  being  used,  whether  the  aircraft  are  on  common  departure 
routings,  and  whether  special  procedures  are  in  effect  (e.g.,  San  Francisco 
to  Los  Angeles  departures  restricted  to  10  nautical  mile  spacing) .  The 
departure  control  logic  of  AADM  may  be  applied  to  all  selected  runway 
configurations. 

C .  AADM  Refinements 

The  AADM  was  developed  by  SRI  using  the  airspace  and  multiple  airport 
system  of  the  FAA's  Oakland  Bay  TRACON  as  a  test  model  and  reference  point 
to  guide  the  design  and  structuring  of  the  program.  Thes  test  bed  was 
of  suitable  complexity  to  enable  development  of  the  software  structure  to 
the  level  of  sophistication  needed  to  depict  real-world  operations.  How¬ 
ever,  further  experimentation  is  required  to  check  out  some  of  the  more 
intricate  details  of  the  model  and  to  refine  its  operation  to  ensure  confi¬ 
dence  in  its  general  use.  The  current  level  of  model  development  is  at  a  stage 
that  would  permit  refinements  to  be  made  in  conjunction  with  a  model  valida¬ 
tion  effort.  Refinements  envisioned  include  model  adjustments  that  would 
further  generalize  the  logic,  increase  the  processing  efficiency  of  the 
program  code,  increase  ease  of  use,  provide  additional  output  options,  or 
expand  modeling  capabilities  (e.g.,  additional  control  strategy,  real  time 
workload  assessment,  communication  loading  analysis,  or  fuel  consumption 
estimation  routines). 
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FIGURE  7.  DEPARTURE  CONTROL 
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II  AADM  STRUCTURE 

The  structural  design  of  AADM  is  greatly  influenced  by  the  structure 
of  the  SIMSCRIPT  II. 5  computer  language  in  which  it  is  coded.  Within  the 
language  are  structural  elements  called  entities.  A  model  entity 
may  correspond  to  a  real-world  object  or  process,  or  it  may  be  a  modeling 
artifact  to  facilitate  the  coding  of  logic.  An  entity  may  have  attributes. 
These  attributes  describe  the  entity.  An  attribute  may  be  a  physical 
characteristic  or  parameter,  a  descriptor  of  the  state  of  the  entity,  or 
information  pertaining  to  the  internal  logic  of  the  model. 

Another  structural  element  within  the  SIMSCRIPT  language  is  called  an 
event.  Events  are  time-dependent  occurrences  that  control  the  flow  of  logic 
within  the  simulation.  These  events  may  be  external  or  internal  in 
nature.  External  events  are  those  which  are  directly  controlled  by  the 
user  of  a  model  via  input  data.  Internal  events  are  those  generated  within 
the  model  as  a  result  of  the  programmed  logic.  The  SIMSCRIPT  timing 
routine  and  event  processor  automatically  keeps  track  of  pending  events, 
advances  the  simulation  clock,  and  executes  the  event  that  is  due  to 
occur  next.  The  execution  of  an  event  involves  the  exercise  of  some  model 
logic.  This  may  include  exercising  model  routines,  updating  the  values 
of  the  attributes  of  entities,  scheduling  additional  events,  cancelling 
pending  events,  etc. 

In  the  remainder  of  this  section,  the  entities,  attributes,  and  events 
of  AADM  are  described.  This  information  is  useful  because  it  demonstrates 


how  physical  objects,  processes,  and  parameters  are  represented  in  the  AADM 


simulation.  It  is  also  Indicative  of  the  level  of  detail  at  which  the 
logic  operates,  the  sensitivity  of  the  model  to  various  parameters,  the 
control  and  flow  of  logic,  and  the  real-world  events  which  the  model  is 
designed  to  handle. 

A.  Simulation  Entities 

The  major  simulation  entities  of  AADM  include: 

•  Nodes 

•  Links 

•  Routes 

•  Sectors 

•  Aircraft 

•  Airports. 

Brief  descriptions  of  these  entities  and  some  of  their  associated  attributes 
(i.e.,  descriptive  parameters)  follow. 

1.  Nodes 

A  node  represents  a  point  in  three-dimensional  space.  It  may  corres¬ 
pond  to  a  navigational  fix  (VOR,  marker,  or  intersection),  an  airport,  a 
point  along  a  route  at  which  an  altitude  or  direction  change  is  required, 
or  a  point  at  which  an  aircraft  may  enter  the  modeled  airspace.  A  node 
may  be  joined  to  as  many  other  nodes  as  required,  each  by  a  single  link. 

A  node  is  further  defined  in  terms  of  a  set  of  attributes.  Attributes 
which  are  specified  by  user  input  include  the  altitude  of  the  node,  the 
strategy  to  be  used  to  place  aircraft  on  links  approaching  the  node,  the 
maximum  number  of  aircraft  that  may  be  held  at  the  node,  and  the  type  of 
logic  to  be  used  to  determine  if  an  aircraft  can  enter  a  link  approaching 
the  node  if  there  are  aircraft  being  held  at  the  node.  The  user  also 
specifies  a  minimum  separation  distance  for  aircraft  approaching  the  node 
that  is  due  to  sequencing  or  flow  control.  This  spacing  may  be  changed  by 
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che  AADM  logic  which  periodically  adjusts  strategic  spacing 
constraints  based  on  traffic  and  airport  conditions. 

A  node  also  has  several  parameters  which  designate  additional  properties 
that  a  node  might  possess.  These  parameters  are  used  to  identify  a  node 
as  an  airport/airspace  interface  node,  a  critical  bottleneck  in  the  system 
where  look-ahead  control  logic  is  desired,  or  a  point  where  flow  control 
logic  is  to  be  employed.  In  addition,  several  attributes  are  maintained  to 
describe  the  current  state  at  a  node  for  use  in  the  model  logic. 

2 .  Links 

A  link  is  a  path  between  two  nodes  with  a  given  length  in  nautical 
miles  and  magnetic  heading  in  degrees.  A  link  may  be  a  curved  path; 
however,  in  such  cases,  the  mean  link  heading  will  be  used  to  approximate  the 
effect  of  wind  on  aircraft  traveling  on  the  link.  A  link  carries  single 
directional  traffic  only  and  is  therefore  defined  in  terms  of  a  from-node 
and  a  to-node.  A  link  can  belong  to  a  specific  windset;  this  is  a  group 
of  links  for  which  direction  and  speed  of  the  wind  in  the  surrounding 
airspace  are  the  same.  A  link  may  also  belong  to  a  specific  sector;  this 
is  discussed  in  the  sector  section.  A  mate  may  also  be  designated  for  a 
link.  Attempts  are  made  to  control  aircraft  in  pairs  along  mated  links. 

This  simulates  such  procedures  as  final  approach  to  closely-spaced  parallel 
runways  under  VTR  conditions. 

A  link  is  further  defined  in  terms  of  five  other  parameters:  the 
maximum  number  of  aircraft  allowed  on  the  link,  the  maximum  time  any  air¬ 
craft  may  be  vectored  on  the  link,  the  link  type,  the  overtake  flag,  and 
the  ordering  flag.  The  link  type  refers  to  a  particular  set  of 
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maximum,  nominal,  and  minimum  speeds  for  each  aircraft  type  when  travel¬ 
ing  on  the  link.  The  overtake  flag  indicates  whether  an  aircraft  entering 
a  link  is  allowed  to  overtake  slower  aircraft  already  on  the  link.  The 
ordering  flag  indicates  whether  attempts  are  to  be  made  to  avoid  having 
light  aircraft  trailing  heavy  aircraft. 

3 .  Routes 

A  route  is  an  ordered  set  of  nodes  that  an  aircraft  will  encounter 
between  its  origin  node  and  its  destination  node.  Either  the  first  node, 
the  last  node,  or  both  may  be  defined  as  airports.  The  exact  sequence  of 
nodes  followed  by  an  aircraft  transiting  the  airspace  is  not  fixed.  It 
is  dependent  upon  the  airport/airspace  traffic  routing  plan  in  effect  when  the 
aircraft  enters  the  airspace  and  is  sensitive  to  any  changes  in  the  traffic 
plan  while  the  aircraft  is  transiting  the  airspace.  Route  defini¬ 
tion  allows  the  specification  of  aircraft  rerouting  and  the  transition 
between  traffic  plans  for  aircraft  in  the  modeled  airspace. 

4 .  Sectors 

The  sector  entity  in  AADM  allows  sectorization  of  the  airspace  to  be 
represented.  Each  sector  consists  of  a  gToup  of  links  that  make  up  its 
airspace.  Each  sector  may  have  a  maximum  workload  or  maximum  number  of 
aircraft  associated  with  it.  If  an  aircraft  attempts  to  enter  a  link  in 
a  loaded  sector, it  will  be  held  at  its  current  node  until  the  sector 
becomes  unsaturated. 

5.  Aircraft 

Each  aircraft  entity  has  associated  with  it  the  type,  a  route, 
a  total  delay  incurred,  and  a  number  of  parameters  that  describe  current 


position  and  progress  in  the  system.  Every  aircraft  type  has  a  number, 
an  alphanumeric  name,  minimum,  nominal,  and  maximum  speed  for  each  link 


type,  and  a  minimum  ceiling  and  runway  visual  range  allowable  for  landing. 

In  addition,  every  pair  of  types  has  a  minimum  separation  distance  associated 
with  it.  The  traffic  loading  of  the  airspace/airport  system  is  controlled 
by  the  user  through  the  events  ARRIVAL,  DEPARTURE,  MULTARR,  and  MULTDEP. 
These  events  control  the  traffic  distribution  in  terms  of  aircraft  types, 
routes,  and  time  distributions  for  airborne  aircraft  entering  the  airspace 
and  aircraft  requesting  departure  clearance  at  airports  in  the  system. 

The  time  distribution  of  aircraft  may  be  deterministic  or  stochastic. 

u.  Airports 

Each  airport  has  an  alphanumeric  identifier  and  is  associated  with 
one  or  more  airport/airspace  interface  nodes.  An  airport  has  a  current 
value  of  ceiling  and  runway  visual  range,  both  of  which  may  be  changed 
with  a  weather  event.  The  ceiling  and  runway  visual  range  of  the  airport 
is  used  in  conjunction  with  the  minimum  ceiling  and  minimum  runway  range 
of  a  particular  category  of  aircraft  to  determine  whether  an  aircraft  can 
land  or  must  execute  a  missed  approach. 

For  each  airport/airspace  interface  node,  a  set  of  allowable  departure 
and  arrival  procedures  is  defined  for  each  airport/airspace  plan.  Each 
procedure  is  defined  in  terms  of  constraints  on  other  procedures  due  to 
runway  occupancy  times  and  airspace  separation  requirements.  The  level 
of  detail  of  representation  of  airport  operating  procedures  is  controlled 
by  the  definition  of  procedures,  which  allows  an  airport  to  be 
represented  simply  by  a  node  with  an  entry/exit  rate  constraint  or  by 


a  complex  multirunway  operating  plan  with  complex  Interactions  between 
departures  and  arrivals.  Departure  route  separation  restrictions  and 
interrelationships  between  operations  at  different  airports  in  the  modeled 
system  may  be  treated- 

B.  Simulation  Events 

External  events  allow  the  user  to  control  the  flow  of  logic  via  input 
data.  At  any  time  during  the  simulation  the  user  can  designate  an  external 
event  to  occur.  The  external  events  of  AADM  include: 

•  Arrival 

•  Multarr 

•  Departure 

•  Multdep 

•  Wind 

•  Weather 

•  Plan 

•  Trace. 

A  general  description  of  these  events  follows.  There  are  also  internal  events 
which  are  scheduled  by  the  internal  simulation  logic.  These  are  more  closely 
associated  with  the  simulation  logic  and  are  described  in  a  later  section  of 
this  report. 

1 .  Arrival 

The  arrival  event  provides  the  user  with  the  capability  to  specify  that 
an  aircraft  of  a  given  type  will  arrive  in  the  modeled  airspace  on  a 
specific  route  at  a  specific  time.  Thus,  a  user  could  specify  a  deter¬ 
ministic  aircraft  arrival  schedule  using  this  event. 

2.  Multarr 

The  multarr  event  provides  the  user  with  the  capability  to  specify  a 
stochastic  time  distribution  of  aircraft  arrivals.  Parameters  of  this 
event  include  type  of  aircraft,  the  arrival  route,  the  number  of  aircraft 
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to  arrive,  the  statistical  time  distribution  of  arrivals,  and  the  time 
interval  over  which  the  arrivals  are  to  be  distributed. 

3 .  Departure 

This  event  is  analogous  to  the  arrival  event  with  the  exception  that 
it  is  concerned  with  prescribing  of  aircraft  departure  requests  at  airports. 

4 •  Multdep 

The  multdep  event  is  analogous  to  the  multarr  event  for  airport  departures. 

5.  Wind 

The  wind  event  provides  the  user  with  the  capability  to  change  wind 
conditions  at  any  time  during  the  simulation.  The  wind  condition  may  be 
changed  separately  for  each  set  of  links  in  a  windset.  The  parameters  in 
this  event  are  the  windset  number  for  which  wind  conditions  are  changing 
and  the  new  values  of  the  wind  direction  and  speed. 

6.  Weather 

The  weather  event  enables  the  user  to  modify  the  visibility  conditions 
at  an  airport  in  the  system  at  any  time  during  the  simulation.  The  parameters 
include  the  airport  at  which  conditions  are  changing,  the  new  values  of 
the  ceiling,  and  the  runway  visual  range  at  the  designated  airport. 

7.  Plan 

The  plan  event  provides  the  user  with  the  capability  to  trigger 
a  traffic  plan  change  at  any  time  during  the  simulation.  The 
parameters  of  this  event  include  the  new  plan  number*  a  flag  to  specify 
whether  or  not  all  departures  under  the  new  plan  are  to  be  held  until 
arrivals  under  the  old  plan  which  are  too  close  to  the  airport  to  be 
rerouted  have  landed,  and  the  minimum  time  period  during  which  departures 
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are  to  be  held  (e.g.,  to  simulate  taxiing  to  a  new  departure  runway).  This 
event  triggers  rerouting  of  aircraft,  resetting  of  strategic  traff^'.  flow 
constraints,  etc.,  to  simulate  a  plan  change. 

8.  Trace 

One  form  of  output  of  AADM  is  a  detailed  accounting  of  the  progress 
of  each  aircraft  through  the  system.  The  trace  event  provides  the  user 
with  flexibility  to  turn  this  output  on  and  off  at  will  during  the  simula¬ 
tion.  This  permits  the  user  to  obtain  detailed  simulation  log  output  only 
during  chose  periods  of  the  simulation  when  such  output  may  be  of  special 
interest  (e.g.,  for  a  period  of  time  after  a  plan  change). 
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Ill  AADM  PROGRAM  LOGIC 


A.  Definition  of  Routines 

The  SIMSCRIPT  II. 5  program  for  AALM  comprises  over  60  routines. 

A  list  of  these  routines,  together  with  brief  descriptions  of  the 
routines, follows : 

AIRPORT. INPUT — This  routine  is  called  by  MAIN  to  read  and 
process  user  input  for  the  keyword  "AIRPORT."  This  includes  definition 
of  each  airport  in  the  system  in  terms  of  associated  airport/airspace 
interface  nodes  and  departure  and  arrival  procedures  to  be  used  under  each 
plan  for  each  of  these  nodes. 

ARRIVAL — This  event  routine  is  called  when  an  arrival  event 
occurs.  It  creates  the  arriving  aircraft  entity  and  initializes  its 
attributes.  Control  logic  is  then  called  upon  to  determine  the  aircraft 
movement. 

CONTROL — This  routine  is  the  key  driver  routine  in  determining 
aircraft  movements  at  Levels  I  and  II.  It  calls  upon  routines  which 
contain  the  various  alternative  control  strategies. 

DEPARTURE — This  event  routine  is  executed  whenever  a  departure 
event  occurs.  It  creates  a  departure  request,  records  data  about  this 
request,  and  places  the  request  on  the  departure  queue  at  the  appropriate 
airport. 

EARLY • TO A — This  routine,  which  supports  several  control  logic 
routines,  is  used  to  determine  the  earliest  time-of-arrival  of  an  air¬ 
craft  at  the  next  node  along  its  route. 
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EJECT — This  routine  is  called  when  an  aircraft  has  left  the 


system,  having  either  transited  the  airspace  or  landed  at  an  airport. 

Relevant  statistics  are  updated  and  the  aircraft  entity  is  destroyed. 

END. REP — This  routine  prints  a  final  report  of  the  simulation 
results  and  then  stops  the  simulation. 

END. SEED — This  event  routine  is  called  at  the  end  of  the  simula¬ 
tion  seed  time.  Various  counters  are  reinitialized  and  a  report  of  results 
is  printed. 

END. SIM — This  event  routine  is  called  at  the  time  the  simulation 
is  terminated.  It  calls  routine  END. REP  to  have  a  final  report  printed. 

ENDDELAY — This  event  routine  is  executed  when  an  aircraft  is 
expected  to  be  able  to  leave  a  holding  queue  and  proceed  along  its  route. 

FIX, AIR. TIMES — This  routine  is  called  when  the  aircraft  arrives 
at  the  airport/airspace  interface  node  upon  departure;  it  sets  minimum 
times  for  subsequent  related  procedures  based  upon  airspace  constraints. 

It  also  sets  any  relevant  route  restriction  constraints.  The  routine  is 
also  called  when  an  aircraft  is  on  its  final  link  into  an  airport  to  set 
logic  which  will  prevent  departure  procedures  from  occurring  when  the 
arriving  aircraft  is  too  close  to  the  airport. 

FLOW. INPUT — This  routine  reads  and  processes  input  data  associa¬ 
ted  with  the  keyword  "FLOWS."  These  data  specify  the  Level  III  control 
parameters. 

FLOW . UPDATE — This  event  routine  calls  upon  the  logic  which  recomputes 
and  resets  the  Level  III  separation  distances.  It  also  schedules  the  next 
periodic  Level  III  update  based  on  the  user  defined  frequencies  for  these 
updates. 
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FORCE FIT  — This  routine  places  an  aircraft  at  a  specified  position 
in  the  arrival  queue  at  a  node.  Conflicts  are  resolved  by  controlling  the 
entering  aircraft,  its  predecessor  in  the  arrival  queue,  and  as  many  suc¬ 
ceeding  aircraft  as  necessary. 

HOLDCHECK — This  routine  determines  if  an  aircraft  must  be  held 
at  its  current  node  position  because  of  the  holding  situation  at  its 
current  node,  the  next  node,  or  a  link  capacity  constraint. 

LANDING — This  routine  includes  the  logic  for  attempting  a  landing 
at  an  airport.  Routines  MISS ED. APPROACH,  EJECT,  and  NEXTDEPARTl'RE  are 
called  upon  as  appropriate. 

LATE . TOA — This  support  routine  computes  the  latest  time-of-arrival 
of  an  aircraft  at  the  next  node  along  its  route. 

LINK . INPUT — This  routine  reads  and  processes  input  data  for  the 
keyword  "LINKS." 

LINK1,  LINK2,  LINK3 — These  routines  are  called  when  the  keyword 
"GO"  is  encountered.  The  various  types  of  input  data  are  linked  together, 
error  checking  is  done,  and  data  are  loaded  in  the  form  required  to  initiate 
the  simulation. 

MAIN — This  routine  acts  on  the  control  program  module  during 
the  data  input  phase.  It  reads  input  keywords  and  passes  control  to  the 
appropriate  input  routines.  It  calls  routines  for  linking  the  input  data 
and  printing  the  input  data,  then  starts  the  simulation  which  passes  control 
to  the  SIMSCRIPT  TIMING  ROUTINE. 

* 

Not  yet  implemented. 
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METERCONTROL — This  routine  provides  one  strategy  for  Level  II 


control  logic-  It  looks  ahead  to  designated  "POST"  nodes  and  checks  for 
future  conflicts.  If  a  future  conflict  exists,  control  actions  are  taken 
to  eliminate  partially  or  fully  the  anticipated  conflict. 

METERING. INPUT — This  routine  is  called  to  read  and  process  input 
data  for  the  Level  II  control  strategy  when  the  keyword  "METERING"  is 
encountered  by  MAIN. 

* 

MIS SEP. APPROACH  — This  routine  is  called  when  an  aircraft  on  final 
approach  must  execute  a  missed  approach. 

MOVE CHECK — This  event  routine  checks  to  determine  whether  a 
holding  aircraft  can  be  cleared  to  proceed  along  its  route. 

MULTARR — This  event  routine  is  exercised  when  the  user  specifies 
an  external  event  MULTARR.  The  routine  generates  ARRIVAL  events  according 
to  the  user  input  specification. 

MULTDEP — This  event  routine  generates  DEPARTURE  events  according 
to  the  user  input  data  when  an  external  event  MULTDEP  occurs . 

MULTFIT — This  event  routine  attempts  to  place  the  aircraft  at  a 
specified  position  in  a  node  arrival  queue  by  controlling  the  entering 
aircraft  and  the  aircraft  preceding  and  following  it  on  the  queue.  Attempts 
to  resolve  conflicts  include  controlling  the  entering  and  preceding  air¬ 
craft,  then  the  entering  and  succeeding  aircraft,  and  finally  controlling 
all  three  aircraft. 

■k 

Not  fully  implemented. 
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NEXTDEPARTtTRE — This  routine  determines  the  next  departure  to 
occur  at  an  airport  and  schedules  a  TAKEOFF  event  at  the  expected  clear-to- 
roll  time.  This  routine  is  called  when  anything  occurs  at  an  airport 

which  may  affect  the  next  departure. 

NODE .ARRIVAL — This  event  routine  is  exercised  whenever  an  air¬ 
craft  arrives  at  a  node.  It  calls  upon  logic  to  land,  eject,  or  move  the 
aircraft  toward  its  next  node  as  appropriate. 

NODE . DEPARTURE — This  routine  embodies  the  logic  involved  with 
releasing  an  aircraft  from  its  current  position  at  the  link  leading  to  the 
next  node  along  its  route.  It  calls  upon  routine  CONTROL  to  determine 
necessary  control  actions. 

NODE . INPUT — This  routine  reads  and  processes  user  input  for  the 
keyword  "NODES."  These  data  include  definition  of  the  nodes  for  the  system 
being  modeled. 

NOMFIT — This  routine  places  an  aircraft  in  a  node  arrival  queue 
at  the  position  of  order  at  which  it  "normally"  would  arrive  without  any 
control  actions,  if  a  conflict  would  not  result.  The  nominal  position  is 
based  on  the  arrival  time  of  the  aircraft  at  the  node  assuming  it  travels 
the  link  at  the  user  input  nominal  speed  for  the  link. 

OKMOVE — This  routine  checks  to  determine  whether  an  aircraft  at  a  node 
must  be  held  there  based  on  the  user-specified  holding  strategy  at  the  node. 

PAIRCONTROL — This  routine  embodies  the  logic  for  controlling 
aircraft  in  pairs  along  mated  links  (e.g.,  final  approach  links  to  closely 
spaced  parallel  runways  under  VFR  conditions) .  This  logic  pairs  aircraft 
as  they  approach  the  initial  node  of  the  mated  links  and  takes  control 
actions  for  pairs  of  aircraft  on  the  mated  links  to  simulate  side-by 
flight . 
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PERIODIC . REP — This  event  routine  is  executed  periodically  to 


print  a  report  of  results  for  each  time  period  of  the  simulation.  It 
schedules  the  next  PERIODIC . REP  event . 

PLAN — This  event  routine  is  executed  when  a  user  specified  plan 
event  occurs.  It  contains  logic  for  resetting  variables  required  for 
turning  around  the  airport  and  airspace  operations,  including  the  transition 
between  plans. 

PLAN . INPUT — This  routine  is  called  by  MAIN  when  the  keyword 
"PLANS"  is  encountered.  It  reads  and  processes  data  which  specify  mappings 
of  routes  among  the  airport/airspace  plans. 

POSTING — This  routine  removes  an  aircraft  from  the  list  of  air¬ 
craft  chat  are  approaching  a  given  LEVEL  II  node  when  the  aircraft  has 
arrived  there. 

PREAMBLE — This  SIMSCRIPT  module  defines  the  structure  of  the  AADM 
simulation.  It  defines  the  entities,  attributes,  events,  and  variables 
and  arrays  which  are  common  to  all  routines. 

PRINT. INPUT — This  routine  is  called  by  MAIN  when  the  keyword 
"PRINT"  Is  encountered.  It  provides  the  user  with  the  capability  to  select 
the  types  of  input  data  for  which  a  printout  is  desired. 

PRINT1,  PRINT2 — These  routines  provide  a  printed  version  of  the 
various  types  of  input  data. 

PROCBLOCK — This  event  routine  implements  the  constraints  that 
prevent  departure  procedures  when  an  aircraft  on  final  approach  is  too 
close  to  the  airport. 
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PROCEDURE . INPUT — This  routine  is  called  by  MAIN  whenever  the 
keyword  "PROCEDURES"  is  encountered.  It  processes  input  data  which  specify 
the  runway  occupancy  time  and  airspace  distance  constraints  among  airport 
arrivals  and  departures. 

QFIFO — This  routine  contains  control  logic  to  place  an  aircraft 
last  in  a  node  arrival  queue,  initiating  any  control  actions  required  to 
resolve  conflicts.  All  control  actions  are  imposed  on  the  entering  aircraft. 

REPORTER — This  routine  is  called  upon  by  event  routines  END. SEED 
and  PERIODIC. REP  in  printing  simulation  reports. 

RESET — This  routine  supports  several  control  routines.  It  contains 
the  logic  for  resetting  parameters  and  rescheduling  events  when  a  control 
action  is  taken  on  an  aircraft  or  a  link  (instead  of  at  a  node). 

ROUTE . INPUT — This  routine  is  exercised  when  the  keyword  "ROUTES" 
is  read  by  MAIN.  It  reads  and  processes  data  which  define  the  rouLe 
structure  of  the  simulation. 

SECTOR. INPUT — This  routine  is  called  by  MAIN  when  the  keyword 
"SECTORS"  is  encountered;  it  reads  and  processes  data  that  define  the  airspace 
sectorization. 

SETFLOWS — This  routine  periodically  computes  Level  III  flow 
constraints  at  the  flowmeter  nodes  based  on  current  and  expected  traffic 
loading  and  sets  the  strategic  separation  distances. 

SPEED FIT — This  Level  I  control  routine  attempts  to  place  the  air¬ 
craft  at  a  given  position  of  order  in  a  node  arrival  queue.  Only  control 
actions  (e.g.,  speed  changes,  vectoring,  holding)  on  the  entering  air¬ 


craft  are  considered. 


TAKEOFF — This  event  routine  contains  the  logic  required  to 


simulate  an  aircraft  takeoff  from  an  airport. 

TIMING. INPUT — This  routine  is  executed  when  the  keyword  "TIMING" 
is  encountered  in  MAIN.  It  reads  and  processes  data  which  set  the  simu¬ 
lation  seed  time,  end  time,  and  frequency  of  periodic  reports  of  simulation 
resul ts. 

TOSH — This  routine  computes  the  minimum  separation  between  two 
aircraft  at  a  node.  The  separation  depends  upon  minimum  wake  turbulence 
separations  based  on  aircraft  type  as  well  as  any  strategic  separation 
distances  set  at  the  node  for  controlling  traffic  flow. 

TRACE — This  event  routine  is  exercised  when  a  TRACE  event  is 
specified  by  the  user.  It  provides  for  turning  the  detailed  simulation 
log  output  on  and  off  at  will  during  the  simulation. 

TRACE . INPUT — This  routine  is  called  by  MAIN  when  the  keyword 
"TRACE"  is  encountered.  It  reads  input  data  which  specify  the  output 
desired  in  the  simulation  log. 

TYPE . INPUT — This  routine  is  called  by  MAIN  upon  encountering  the 

keyword  "AIRCRAFT."  It  reads  and  processes  data  that  specify  the  speed 
range  for  each  aircraft  type  for  each  type  of  link.  The  minimum  separation 
distance  between  each  pair  of  aircraft  types  is  also  specified. 

UNSAT — T-'s  routine  contains  logic  that  releases  aircraft  from 
holding  due  to  sector  saturation  whenever  the  sector  becomes  unsaturated. 

WAKE TURBULENCE — This  routine  is  used  when  the  user  has  specified 
that  it  is  not  desirable  to  have  light  aircraft  behind  heavy  aircraft  on  a 
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given  link.  For  a  given  position  in  a  node  arrival  queue,  this  routine 
determines  if  placement  of  an  arriving  aircraft  is  desirable  based  upon 
wake turbulence  separation  requirements. 

WEATHER — This  event  routine  is  exercised  whenever  a  user  specified 
WEATHER  event  occurs.  It  contains  logic  to  modify  the  ceiling  and  runway 
visual  range  at  an  airport. 

WIND — This  event  routine  is  exercised  when  a  WIND  event  occurs. 

It  contains  logic  for  changing  the  wind  direction  and  speed  for  the  links 
in  a  given  windset. 

WIND. INPUT — This  routine  is  called  by  MAIN  when  the  keyword  "WIND" 
is  encountered.  It  reads  and  processes  data  defining  the  various  windsets, 

i.e.,  groups  of  links  that  have  the  same  wind  conditions  in  the  surrounding 
airspace. 

These  routines  function  within  five  major  logical  segments  of  the  AADM 
program.  These  segments  are 

•  Input  lobic 

•  External  event  processing  logic 

•  Simulation  report  logic 

•  Airspace  traffic  control  logic 

•  Airport/airspace  interface  simulation  logic. 

Flowcharts  demonstrating  the  interrelationships  among  routines  functioning  in 
each  of  the  logical  segments  are  presented  in  Figures  8  through  12.  The 
coupling  among  the  segments  is  depicted  in  this  set  of  figures.  Descriptions 
of  each  of  the  logical  segments  of  AADM  follow. 

B .  Input  Logic 

A  flowchart  of  the  AADM  input  logical  segment  is  presented  in  Figure 
8.  At  the  beginning  of  a  program  operation,  MAIN  has  control  of 
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FIGURE  8.  FLOWCHART  OF  AADM  INPUT  LOGIC 
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FIGURE  9.  FLOWCHART  OF  AADM  EXTERNAL  EVENT  PROCESSING  LOGIC 
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FIGURE  10.  FLOWCHART  OF  AADM  SIMULATION  REPORT  LOGIC 


NODE. ARRIVAL  , 
^  *  -  --  - 


^  PROCBLOCT  I  RESET 


NODE. ARRIVAL 
I - -  -  -  ■* 


LATE . TOA 


FIGURE  11.  FLOWCHART  OF  AADM  AIRSPACE  TRAFFIC  CONTROL  LOGIC 
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program  execution.  The  major  function  of  MAIN  is  to  control  reading  of 
the  input  data,  processing  of  the  data  into  the  form  required  to  perform 
the  simulation,  and  printing  of  the  input  data  for  user  reference  and 
verification. 

The  input  data  to  AADM  are  grouped  into  14  categories,  four  of  which  are 
required.  Each  category  is  preceded  by  a  keyword  which  triggers  a  call 
to  an  appropriate  input  routine  which  reads  and  processes  the  type  of  data 
in  the  category.  Each  keyword,  the  input  routine  associated  with  the 
keyword,  and  whether  or  not  the  data  category  is  required  are  given  in 
Table  1. 

The  keyword  "GO"  is  inserted  at  the  end  of  the  input  data.  When  this 
keyword  is  encountered  the  data  for  all  the  previous  input  sections  are 
linked  by  routines  LINK1 ,  LINK2 ,  and  LINO.  PRINT1  and  PRINT2  are  then 
called  to  print  a  version  of  the  input  data  in  a  format  to  facilitate  user 
reference  and  checking.  MAIN  then  schedules  the  first  FLOW. UPDATE  event  if 
Level  III  is  being  used.  The  simulation  is  then  started  and  control  of 
the  program  is  passed  to  the  TIMING  ROUTINE,  an  internal  SIMSCRIPT  routine 
which  controls  simulation  timing  and  event  processing.  The  TIMING  ROUTINE 
keeps  track  of  all  scheduled  events  and  triggers  the  execution  of  events  in 
proper  time  sequence.  When  an  event  occurs,  the  event  routine  with  the 
same  name  as  the  event  is  executed.  This  event  routine  can  call  upon 
ocher  logical  routines  as  necessary. 


Table  1 


INPUT  DATA  CATEGORIES 


Reword 

Required 

Input  Routine 

AIRPORTS 

No 

AIRPORT. INPUT 

FLOWS 

No 

FLOW. INPUT 

LINKS 

Yes 

LINK . INPUT 

NODES 

Yes 

NODE . INPUT 

PLANS 

No 

PLAN . INPUT 

PRINT 

No 

PRINT . INPUT 

PROCEDURES 

No 

PROCEDURE . INPUT 

ROUTES 

Yes 

ROUTE . INPUT 

SECTORS 

No 

SECTOR. INPUT 

TRACE 

No 

TRACE . INPUT 

AIRCRAFT 

Yes 

TYPE. INPUT 

WIND 

No 

WIND . INPUT 

METERING 

No 

METERING . INPUT 

TIMING 

No 

TIMING. INPUT 

C.  External  Event  Processing  Logic 

The  external  events  for  the  simulation  are  specified  by  the  user 
at  the  end. of  the  input  data  file.  The  time  each  event  is  to  occur 
as  well  as  the  parameters  associated  with  each  event  are  read.  The 
interval  SIMSCRIPT  TIMING  ROUTINE  schedules  and  executes  each  of  these 
events  at  the  specified  time  by  exercising  an  event  routine  with  the  same 
name  as  the  event. 

A  flowchart  of  the  logical  segment  for  processing  these  events  is 
shown  in  Figure  9.  Since  the  ARRIVAL  event  deals  with  an  aircraft 
entering  the  airspace,  the  ARRIVAL  event  routine  is  coupled  to  the  ATC 
simulation  logic  for  determining  aircraft  movement.  Similarly,  since  a 
DEPARTURE  event  involves  an  aircraft  requesting  clearance  to  take  off,  the 
DEPARTURE  event  routine  is  coupled  to  the  airport/airspace  interface  logic. 
Since  the  PLAN  event  may  affect  airport  operations,  the  PLAN  event  routine 
is  also  coupled  to  the  airport/airspace  interface  logic.  The  events  that 
are  scheduled  by  the  various  event  routines  are  indicated  by  the  dashed  arrows. 
MULTARR  schedules  ARRIVAL  and  FLOW. UPDATE  events,  MULTDEP  schedules 
DEPARTURE  events,  and  PLAN  schedules  MOVECHECK  and  FLOW. UPDATE  events. 

(Refer  to  the  preceding  description  of  the  event  routines  with  the  same 
name  as  these  events  for  information  about  their  function.)  The  TIMING 
ROUTINE  records  all  of  these  scheduled  events  and  causes  them  to  occur  at  the 
scheduled  times. 

D.  Simulation  Report  Logic 

The  AADM  program  segment  that  controls  the  printing  of  simulation 
results  is  shown  in  Figure  10.  Three  events  are  included  in  this  logic: 
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END. SIM,  END. SEED, and  PERIODIC. REP.  The  END. SIM  event  is  executed  if  the 


time  specified  as  the  maximum  run  time  for  the  simulation  is  reached.  This 
event  calls  upon  the  END. REP  routine,  which  prints  a  final  report  of 
simulation  results  and  then  stops  the  simulation.  (See  Section  IV  for  a 
description  of  the  output.)  The  simulation  will  also  be  ended  if  at  any 
time  during  the  simulation  no  events  are  scheduled.  In  this  case, control 
of  the  program  execution  is  passed  to  MAIN,  which  calls  END. REP. 

The  END. SEED  event  occurs  at  the  end  of  the  simulation  seed  time. 

It  calls  upon  REPORTER  to  print  a  report  of  simulation  results  during  the 
seed  period.  Various  statistics  are  reinitialized  and  the  simulation  is 
resumed.  The  PERIODIC. REP  event  provides  printing  of  simulation 
results  over  time  periods  of  simulation.  The  PERIODIC.REP  event  routine 
schedules  the  next  future  PERIODIC.REP  event  according  to  the  user  specified 
frequency  for  periodic  reports. 

E .  Airspace  Traffic  Control  Logic 

The  simulation  logic  of  AADM  is  designed  to  simulate  the  movement  of 
aircraft  through  an  airspace  by  modeling  three  levels  of  traffic  control: 

•  Level  I — Tactical 

•  Level  II — Sequencing 

•  Level  III — Strategic. 
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A  flowchart  of  the  airspace  traffic  control  logic  segment  is  shown  in 
Figure  11«  A  description  of  each  of  the  three  levels  of  control  logic  follows: 

1.  Level  I— Tactical 

Level  I  is  concerned  with  movement  of  aircraft  from  node  to  node  along 
a  route.  Three  internal  events  control  the  logic  at  this  level:  NODE. ARRIVAL, 
ENDDELAY,  and  MDVECHECR.  Event  NODE. ARRIVAL  performs  required  processing 
when  an  aircraft  arrives  at  a  node.  When  an  aircraft  arrives  at  a  node, 
the  node  is  checked  to  determine  whether  it  is  one  at  which  the  aircraft 
should  be  removed  from  the  system,  i.e.,  an  airport /airspace  interface 
node  or  a  route  exit  node.  In  the  former  case,  the  LANDING  routine  in  the 
airport/airspace  interface  logic  segment  is  executed.  In  the  latter  case, 

EJECT  is  executed.  The  node  of  arrival  is  also  checked  to  see  if  it  is  a 
"POST"  node,  i.e.,  a  node  to  which  Level  II  looks  ahead  in  an  effort  to 
resolve  future  conflicts.  If  so,  POSTING  is  called  to  remove  the  aircraft 
from  future  Level  II  considerations  at  the  node. 

Routine  HOLDCHECK  checks  on  several  conditions  that  would  require  the 
aircraft  to  go  into  holding  at  its  current  node  position.  First  of  all, 
if  the  holding  queue  of  the  node  is  not  empty,  the  aircraft  is  placed  at 
the  end  of  the  queue.  The  aircraft  is  placed  at  the  head  of  an  empty  queue 
if  the  next  link  on  its  route  is  filled,  if  the  status  of  the  holding  queue 
of  the  next  node  will  not  allow  aircraft  movement,  or  if  the  next  sector 
is  filled.  If  the  next  sector  is  filled,  the  holding  node  is  placed  on 
a  list  of  pending  nodes,  whose  holding  queues  are  processed  when  the 
sector  becomes  unsaturated. 

If  the  aircraft  is  not  required  to  hold  based  on  any  of  the  above 
constraints,  NODE . DEPARTURE  is  called.  This  routine  attempts  to  find  a 
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legal  aircraft  movement  using  the  control  strategy  specified  for  the  next 
node.  If  the  aircraft  cannot  proceed  toward  the  next  node  along  its  route 
without  violating  a  constraint  even  under  all  allowable  control  actions, 
it  is  placed  at  the  head  of  the  holding  queue  and  an  ENDDELAY  event  is 
scheduled  for  that  holding  queue.  If  a  iegal  movement  is  found,  a  NODE. 
ARRIVAL  event  is  scheduled  for  the  aircraft  at  the  next  node.  In  any  case, 
the  holding  queues  of  both  the  current  node  and  the  node  the  aircraft  just 
left  are  checked  for  possible  movement  as  a  result  of  this  aircraft  arrival. 

Events  ENDDELAY  and  MOVECHECK  are  both  scheduled  as  a  result  of  holding 
conditions  at  a  node.  When  executed,  they  cause  the  holding  queue  at  a 
node  to  be  checked  for  aircraft  that  may  be  moved.  If  a  potential  legal 
movement  is  detected,  routine  NODE. DEPARTURE  is  called. 

In  the  AADM  program, an  arrival  queue  is  maintained  for  each  node  in 
the  airspace  being  modeled.  The  arrival  queue  for  a  node  is  a  list  of  all 
aircraft  on  links  terminating  at  the  node,  with  the  list  ordered  by  projected 
times  of  arrival  at  the  node.  Routine  CONTROL  is  exercised  to  determine 
the  placement  of  the  aircraft  in  the  arrival  queue  of  the  next  node  along 
its  route  and  to  initiate  any  control  actions  required  to  ensure  that  safe 
separation  and  operating  standards  are  met.  Control  actions  include  speed 
changes,  vectoring,  path-stretching,  and  holding  of  aircraft.  The  strategy 
to  be  used  in  placing  an  aircraft  in  an  arrival  queue  at  each  node  is  a 
user  input.  CONTROL  draws  upon  several  routines  in  implementing  the  various 
control  strategies.  These  routines  include: 
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•  WAKETURB 

•  NOMFIT 

•  QFIFO 

•  SPEEDFIT 

•  MULTFIT 

•  FORCEFIT. 

A  brief  description  of  each  of  these  routines  will  be  provided  before 
describing  the  six  arrival  strategies.  For  the  purposes  of  this  descrip¬ 
tion,  assume  that  an  aircraft  is  arriving  on  a  link  and  attempts  are  being 

made  to  determine  an  appropriate  position  of  order  for  this  arriving  air¬ 

craft  on  the  arrival  queue  of  the  node  at  which  the  link  terminates. 

On  certain  links  in  the  airspace,  it  may  be  desirable  to  maximize 
the  capacity  of  the  link  by  avoiding  the  placement  of  a  light  aircraft 
behind  a  heavy  aircraft,  since  increased  separation  requirements  would  be 
needed  due  to  waketurbulence .  The  WAKETURB  routine  determines  the  preferred 
placement  of  an  arriving  aircraft  in  the  arrival  queue  on  the  basis  of 
waketurbulence  separation  requirements. 

The  NOMFIT  routine  places  the  aircraft  in  the  arrival  queue  at  the 
position  of  order  at  which  it  "normally"  would  arrive  without  any  control 
actions,  if  a  conflict  would  not  result.  The  nominal  position  is  based  on 
the  arrival  time  of  the  aircraft  at  the  node  assuming  it  travels  the  link 

at  the  user  input  nominal  speed  for  the  link  for  that  aircraft. 

The  QFIFO  routine  places  the  aircraft  last  in  the  arrival  queue, 
initiating  any  control  actions  required  to  resolve  conflicts.  All  control 
actions  are  imposed  on  the  entering  aircraft. 

The  SPEEDFIT  routine  attempts  to  place  the  aircraft  at  a  given  position 
of  order  in  the  arrival  queue.  Only  control  actions  (e.g.,  speed 
changes,  vectoring,  holding)  on  the  entering  aircraft  are  considered. 
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The  MULTFIT  routine  attempts  to  place  the  aircraft  at  a  specified 
position  in  the  arrival  queue  by  controlling  the  entering  aircraft  and 
the  aircraft  preceeding  and  following  it  on  the  queue.  Attempts  to  resolve 
conflicts  include  controlling  the  entering  and  preceeding  aircraft,  then 
the  entering  and  succeeding  aircraft,  and  finally  all  three  aircraft. 

The  FORCEFIT  routine  places  an  aircraft  at  a  specified  position  in 
the  queue.  Conflicts  are  resolved  by  controlling  the  entering  aircraft, 
its  predecessor  in  the  arrival  queue  and  as  many  succeeding  aircraft  as 
necessary . 

Each  of  the  six  control  strategies  currently  call  upon  these  routines 
in  a  series  of  steps.  The  steps  are  executed  successively  until  the  air¬ 
craft  is  placed  in  the  queue  with  all  conflicts  resolved.  The  steps  for 
each  strategy  are  as  follows: 

Strategy  1 

Use  QFIFO . 

Strategy  2 

(1)  Try  NOKFIT  at  the  nominal  arrival  position  in  the  queue. 

(2)  Try  SPEEDFIT  at  the  nominal  arrival  position  in  the  queue. 

(3)  Try  SPEEDFIT  at  each  successively  earlier  arrival  position 
in  the  queue. 

(4)  Try  SPEEDFIT  at  each  successively  later  arri*-£l  position  in 
the  queue. 
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Strategy  3 

(1)  Try  NOMFIT  at  the  nominal  arrival  position. 

(2)  Try  SPEEDFIT  at  the  nominal  arrival  position. 

(3)  Try  MULTFIT  at  the  nominal  arrival  position. 

(4)  Repeat  steps  (2)  and  (3)  for  each  successively  earlier  arrival 
position  in  the  queue. 

(5)  Repeat  steps  (2)  and  (3)  for  each  successively  later  arrival 
position  in  the  queue. 

•k 

Strategy  4 

(1)  Try  NOMFIT  at  the  nominal  arrival  poisition. 

(2)  Try  SPEEDFIT  at  the  nominal  arrival  poisition. 

(3)  Try  MULTFIT  at  the  nominal  arrival  position. 

(4)  Use  FORECFIT  at  the  nominal  arrival  position. 

Strategy  5 

(1)  Try  NOMFIT  at  the  nominal  arrival  position  if  WAKETURB 
Indicates  this  to  be  a  desirable  position. 

(2)  Try  SPEEDFIT  at  the  nominal  arrival  position  if  WAKETURB 
indicates  this  to  be  a  desirable  positior  (with  no  path¬ 
stretching  or  holding  permitted) . 

(3)  Try  SPEEDFIT  at  each  successively  earlier  arrival  position 

in  the  queue  at  which  WAKETURB  indicates  a  desirable  position 
(with  no  path-stretching  or  holding  permitted) . 

(4)  Try  SPEEDFIT  at  each  successively  later  arrival  position  in 
the  queue  at  which  WAKETURB  Indicates  a  desirable  position 
(with  no  path-stretching  or  holding  permitted)  . 

(5)  Use  Strategy  2. 

This  strategy  is  not  currently  operational  because  F0RCEFT7  is  not  yet 
coded . 
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(1)  Try  NOMFIT  at  the  nominal  arrival  position  ii  WAKETURB  indicates 
this  to  be  a  desirable  position. 

(2)  Try  SPEEDFTT  at  the  nominal  arrival  position  if  WAKETURB  indi¬ 
cates  this  to  be  a  desirable  position  (with  no  path-stretching  or 
holding  permitted) . 

(3)  Try  MULTFIT  at  the  nominal  arrival  position  if  WAKETURB  indicates 
this  to  be  a  desirable  position  (with  no  path-stretching  or 
holding  permitted). 

(4)  Repeat  steps  (2)  and  (3)  for  each  successively  earlier  arrival 
position  in  the  queue  at  which  WAKETURB  indicates  a  desirable 
position. 

(5)  Repeat  steps  (2)  and  (3)  for  each  successively  later  arrival 
position  in  the  queue  at  which  WAKETURB  indicates  a  desirable 
position. 

(6)  Use  Strategy  3. 

The  number  of  strategies  that  can  be  linked  to  the  CONTROL  routine  is 
unlimited.  The  modular  design  of  the  program  allows  addition  of  other 
alternative  strategies  which  are  identified. 

The  PAIRCONTROL  routine  provides  special  control  logic  for  controlling 
aircraft  in  pairs  along  mated  links.  This  is  useful  in  simulating  such 
operations  as  final  approach  to  closely-spaced  parallel  runways  under  VFR 
conditions.  If  two  links  are  designated  as  mates,  control  actions  are 
taken  to  try  to  have  a  pair  of  aircraft  (one  on  each  of  the  mated  links) 
arrive  at  the  terminal  nodes  of  their  links  at  about  the  same  time.  Air¬ 
craft  are  paired,  if  possible,  on  the  links  feeding  the  mated  links. 


52 


Control  actions  taken  specifically  to  bring  the  paired  aircraft  closer 
together  (in  terms  of  arrival  times  at  the  terminal  nodes  of  the  mated 
links)  are  restricted  to  maintaining  the  aircraft  in  their  current  position 
in  their  node  arrival  queues  and  only  involve  the  aircraft  in  the  pair. 

2.  Level  II — Sequencing 

Level  I  control  of  an  aircraft  is  concerned  with  moving  an  aircraft 
to  the  next  node  along  its  route.  Level  II  is  concerned  with  resolving 
conflicts  at  nodes  beyond  the  next  node  on  its  route.  This  level  of 
control  is  optional.  To  specify  Level  II,  the  user  designates  certain 
nodes  or  "POST"  nodes.  These  are  generally  bottlenecks  or  critical 
merge  points  in  the  airspace  route  network.  For  each  of  these  POST  nodes 
a  set  of  "METER"  nodes  is  designated.  METER  nodes  are  nodes  through  which 
traffic  must  pass  on  the  way  to  the  POST  node.  When  an  aircraft  is  on  anv 
link  between  a  METER  node  and  its  associated  POST  node,  it  is  subject  to 
Level  II  control  actions  (if  it  is  on  a  route  designated  as  one  on  which 
traffic  should  be  controlled  at  Level  II). 

The  Level  II  control  strategy  logic  is  contained  in  routine  METERCON. 

Each  time  an  aircraft  subject  to  Level  II  control  arrives  at  a  node.  Level  I 
control  logic  is  exercised  to  determine  its  movement  to  the  next  node  along  the 
route.  Then  METERCON  is  called  to  provide  a  "look-ahead"  at  the  next  POST 
node  along  the  route.  This  routine  projects  the  status  of  traffic  at  the  POST 
at  the  future  time  that  the  aircraft  would  arrive  there,  assuming  nominal  speed 
beyond  the  next  node.  All  traffic  converging  on  the  POST  node  is  considered 
in  this  "look-ahead."  If  a  future  conflict  with  another  aircraft  is  projected, 
control  actions  are  taken  to  fully  or  partially  alleviate  the  conflict.  In  this 
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strategy.  Level  II  control  actions  are  limited  to  controlling  the  air¬ 
craft  currently  under  consideration  and  maintaining  it  in  the  position  in 
the  node  arrival  queue  determined  at  Level  I. 


Although  only  one  Level  II  strategy, has  been  programmed  to  date,  the 
modular  design  of  the  program  allows  for  additional  strategies  to  be 
easily  added. 

3.  Level  ill — Strategic 

Level  III  control  is  concerned  with  placing  strategic  constraints  on 
traffic  flow  in  terms  of  separation  distances  at  nodes.  These  constraints 
are  aimed  at  balancing  the  flow  of  traffic  into  the  modeled  airspace  to 
prevent  congestion  problems  from  occurring  which  cannot  be  reasonably 
handled  at  Levels  I  and  II.  Level  III  control  is  optional  within  the  AADM 
program. 

The  Level  III  separation  constraints  require  updating  as  traffic  loading 
and  airport  operating  status  change.  The  event  FLOW. UPDATE  triggers  the 
resetting  of  Level  III  separation  distances.  This  event  occurs  periodically 
at  a  user-specified  frequency.  -In  addition,  PLAN  and  MULTARR  events  trigger 
FLOW. UPDATE  events. 

Although  AADM  is  programmed  to  allow  many  Level  III  control  strategies, 
one  strategy  has  been  programmed  to  date.  The  logic  for  this  strategy  is 
contained  in  routine  SETFLOWS.  To  specify  this  Level  III  control,  the  user 
defines  FLOWPOST  nodes.  These  are  generally  bottlenecks  or  critical  merge 
points  in  the  route  network.  Associated  with  each  FLOWPOST  is  a  set  of 
FLOWMETER  nodes.  These  are  entry  nodes  to  the  airspace  that  feed  traffic 
to  the  FLOWPOST.  Also  specified  are  such  parameters  as  the  average  speed 
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of  traffic  flowing  through  each  FLOWPOST  and  FLOWMETER  node  and  the  mini¬ 
mum,  maximum,  and  increment  for  the  allowable  separation  distance  settings 
at  each  FLOWMETER  node. 


When  a  FLOW. UPDATE  event  occurs,  the  number  of  aircraft  expected  to 
flow  through  each  FLOWPOST  during  the  time  period  until  the  next  FLOW. UPDATE 
is  computed.  Likewise,  the  number  of  aircraft  expected  to  nominally  arrive 
at  each  of  the  associated  FLOWMETER  nodes  is  computed.  In-trail  separation 
distances  at  each  of  the  FLOWMETER  nodes  are  set  so  that  the  flow  through 
the  FLOWPOST  node  equals  the  sum  of  the  flows  through  the  associated 
FLOWMETER  nodes.  The  flows  set  for  the  FLOWMETER  nodes  are  proportional  to 
the  traffic  loadings  at  the  nodes. 

F.  Airport/Airspace  Interface  Logic 

A  flowchart  of  the  airport/airspace  interface  logic  segment  of  the 
AADM  program  is  shown  in  Figure  12.  This  logical  segment  is  concerned  with 
simulating  the  movement  of  aircraft  and  control  actions  at  or  near  the 
airport,  including  final  approach,  landing,  and  departure  operations.  As 
seen  from  Figures  11  and  12,  coupling  between  the  airspace  traffic  control 
and  airport/airspace  interface  logic  exists  to  simulate  the  interaction 
between  airspace  and  airport  operations. 

There  are  two  internal  events  which  drive  the  airport/airspace  interface 
logic:  TAKEOFF  and  PROCBLOCX.  In  addition,  a  NODE. ARRIVAL  event  (see 
Figure  11)  triggers  the  LANDING  routine  when  an  aircraft  arrives  at  an 
airport  node.  The  LANDING  routine  contains  logic  for  simulating  an  air¬ 
craft  landing  attempt.  The  first  logical  step  in  this  routine  is  to  check 
to  see  if  the  aircraft  can  be  cleared  to  land.  If  the  runway  visual  range 
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is  insufficient,  the  ceiling  is  too  low,  or  a  previous  landing  or  departure 
conflicts  with  necessary  runway  clearance,  the  aircraft  is  not  cleared 
to  land.  In  this  case, a  missed  approach  must  be  executed,  so  routine 
MISS ED. APPROACH  is  called.  If  the  aircraft  is  cleared  to  land,  constraints 
on  the  occurrence  of  subsequent  landing  and  departure  procedures  are 
updated.  Routine  EJECT  is  then  called  to  purge  the  aircraft  from  the 
airspace  system.  Routine  NEXTDEPARTURE  is  then  called  to  determine  the 
next  aircraft  to  be  considered  for  departure  at  the  airport  and  to  schedule 
a  TAKEOFF  event  for  it.  In  fact,  NEXTDEPARTURE  is  called  whenever  anything 
transpires  chat  may  affect  the  next  departure  to  occur  at  an  airport. 

The  TAKEOFF  event  routine  contains  logic  to  simulate  an  aircraft 
takeoff.  When  a  TAKEOFF  event  occurs,  a  set  of  checks  is  performed  to  ensure 
that  the  associated  aircraft  can  be  cleared  to  roll.  If  a  previous  landing 
or  departure  conflicts  with  necessary  runway  clearance,  if  a  route  separa¬ 
tion  restriction  for  departures  is  violated,  if  departure  restrictions  are 
in  effect  because  of  an  airport  plan  change,  if  airspace  congestion  is 
present  on  the  departure  route,  or  if  an  arriving  aircraft  is  too  close  to 
the  airport,  the  pending  takeoff  is  not  cleared.  If  all  conditions  for  a 
safe  takeoff  are  met,  the  aircraft  is  cleared  to  roll,  constraints  on  the 
occurrence  of  subsequent  landing  and  departure  procedures  are  updated, 
and  an  ARRIVAL  event  is  scheduled  to  occur  at  the  time  the  departing  aircraft 
will  lift  off  and  enter  the  airspace.  Routine  NEXTDEPARTURE  is  then  called 
upon  to  schedule  the  next  potential  TAKEOFF  at  the  airport. 

Event  PROCBLOCK  triggers  the  setting  of  constraints  which  prevent 
departure  procedures  from  occurring  when  an  aircraft  on  final  approach  is 
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too  close  to  the  airport.  When  an  aircraft  enters  the  final  approach 
link,  routine  FIX. AIR. TIMES  schedules  a  PROCBLOCK  event  at  the 

time  the  aircraft  will  be  at  a  point  along  the  approach  path  where  departure 
procedures  begin  to  become  restricted.  Since  various  departure  procedures 
may  be  restricted  at  different  distances  from  the  airport,  succeeding 
PROCBLOCK  events  are  scheduled  as  necessary  as  the  aircraft  progresses 
toward  the  airport. 

In  addition  to  scheduling  PROCBLOCK  events,  the  FIX. AIR. TIMES  routine 
sets  constraints  on  departures  to  reflect  airspace  separation  requirements 
among  departing  aircraft.  These  requirements  include  wake  turbulence 
separations  and  route  separation  restrictions. 
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IV  OUTPUT  OF  SIMULATION  RESULTS 

Three  types  of  output  are  provided  by  the  AADM  simulation:  input 
data  messages,  simulation  log,  and  simulation  reports.  A  description 
and  an  example  of  each  of  these  types  of  output  follow. 

A.  Input  Data  Messages 

In  the  routines  which  read  and  process  the  input  data,  many  checks 
have  been  programmed  to  test  the  consistency  of  the  input  data.  Error 
and  warning  messages  are  printed  to  notify  the  user  of  the  results  of 
these  checks.  A  listing  of  these  error  and  warning  messages  is  shown 
in  Table  2.  Warnings  result  in  corrective  actions  to  ensure  a  simulation 
run.  The  corrective  actions  are  stated  in  the  explanations  of  the  warn¬ 
ings.  Errors  will  result  in  the  program  being  terminated  after  the  input 
phase  of  the  program  is  completed  and  no  simulation  will  be  run. 

B.  Simulation  Log 

A  second  type  of  output  from  AADM  is  a  detailed  log  of  the  simulation. 
An  example  of  portions  of  a  simulation  log  is  provided  in  Table  3.  Infor¬ 
mation  on  the  progress  of  each  aircraft  through  the  modeled  system  is 
printed.  The  time  (in  hours)  is  given,  followed  by  a  description  of  the 
occurrence  or  control  action. 

The  simulation  log  can  be  very  useful  for  program  debugging  as  well 
as  for  detailed  tracking  of  aircraft  through  the  airspace/airport  system. 
This  output  is  optional  and  may  be  turned  on  and  off  at  will  during  the 
simulation  by  use  of  the  TRACE  event. 
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Table  2 


ERROR  AND  WARNING  MESSAGES 


NO.  TYPE 


EXPLANATION 


1  WARNING 

2  WARNING 

3  WARNING 

4  ERROR 

5  ERROR 

6  ERROR 

7  ERROR 
ft  ERROR 

9  WARNING 
10  WARNING 
U  WARNING 

12  WARNING 

13  WARNING 

14  WARNING 


A  LINK  0)1  A  SECTOR  LINK  LIST  IS  UNDEFINED .  NO  ACTION 

IS  TAKEN. 

A  LINK  IS  NOT  FOUND  ON  ANY  SECTOR  LINK  LIST.  IT  IS 
PLACED  IN  THE  FIRST  MODELED  SECTOR . 

THE  TO  CR  FROM.  NODE  OF  A  LINK  IS  UNDEFINED . 

CORRECTIVE  ACTION  WILL  CE  TAKEN  IF  THE  LINK  IS 
SPECIFIED  IN  A  ROUTE. 

A  NODE  USED  IN  A  ROUTE  DEFINITION  IS  UNDEFINED. 

THE  ROUTE  FECOMES  UNDEFINED;  AN  AIFCRAFT  PLACED  ON 
SUCH  A  ROUTE  WILL  PRODUCE  AN  INFCRUATCRY  MESSAGE.  AN 
AIRCRAFT'S  ROUTE  WILL  NOT  CE  CHANGED  TO  AN  UNDEFINED 
ROUTE  AS  A  RESULT  CF  A  PLAN  CHANGE. 

A  CONNECTING  LINK  REQUIRED  IN  A  ROUTE  DEFINITION  IS 
UNDEFINED.  CORRECTIVE  ACTION  IS  THE  SANE  AS  ERROR  4. 
THE  FIRST  ROUTE  CM  A  PLAN  CARD  IS  UNDEFINED.  THE 
CARD  IS  IGNORED. 

A  POST  NODE  IS  UNDEFINED.  NO  METERING  IS  PERFORMED 
AT  ANY  METERING  NODE  ASSOCIATED  WITH  THAT  TOST. 

A  MtTSRJNG  node  IS  UNDEFINED.  NO  METERING  IS 
PERFORMED  AT  ANY  MODE  FOR  THE  ASSOCIATED  POST. 

A  ROUTE  SPECIF  I  ED  AT  A  METERING  ttODE  IS  UNDEFINED. 

NO  ACTION  ID  TAKEN. 

TOO  MANY  MAXIMUM  SPEEDS  APE  DEFINED  FOR  All  AIRCRAFT. 
TYPE.  THE  EXCESS  ARC  IGNORED . 

7 CO  MANY  MINIMUM  SPEEDS  APE  DEFINED  FOR  AN  AIPCRAFT 
TYPE.  THE  E.'.CESS  ARE  IGNORED. 

THE  AMOUNT  OF  SEPARATION  DATA  INPUT  FCP  A  PARTICULAR 
AIRCRAFT  TYPE  IS  INCONSISTENT  WITH  THE  NUMBER  OF 
AIRCRAFT  TYFES.  EXCESS  SEPARATION  DATA  IS  IGNORED. 

IF  TOO  LITTLE  OATA  IS  PROVIDED,  THE  UNDEFINED 
SEPARATIONS  APE  SCT  TO  3  MILES. 

A  LINK  TYPE  IS  HIGHER  THAN  THAT  SPECIFIED  IN  THE 
AIRCRAFT  TYPE  SPEED  DATA.  THE  TYPE  IS  SET  TO  1. 

A  ROUTE  SPECIFIED  AT  A  METERING  CR  FLOWMETER  NODE  IS 
NCT  DEFINED  AT  THE  NODE.  NO  ACTION  IS  TAKEN. 
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Table  2  (Concluded) 


15 

WARNING 

A  LINK  ON  A  WINO  LIST  IS  UNDEFINED.  ,  NO  ACTION  IS 
TAKEN. 

16 

WARMING 

A  LINK  IS  NOT  FOUND  ON  ANY  WIND  LIST.  IT  IS  PLACED 

IN  WINDSET  1. 

17 

WARNING 

rC=E  THAN  ONE  AIRCRAFT  HAS  THE  SAME  MAXIMUM 
SEPARATION.  THE  FIRST  ONE  FOUND  IS  CHOSEN  AS  THE 

THE  HEAVY  TYPE. 

16 

ERROR 

A  PC'JTE  ON  A  PLAN  CARO  IS  UNDEFINED.  THE  MAIN  ROUTE 
REMAINS  AT  ITS  PLAN  1  DEFINITION  FOP  THAT  PLAN. 

19 

EPPCR 

A  METER  NCOS  OR  NODE  INTERNAL  TO  A  METER  CHAIN  HAS 
SEEN  PREVIOUSLY  DEFINED  AS  A  METE0  NODE  CP  PART  OF 

A  METER  CHAIN.  THIS  IS  A  FATAL  ERROR . 

20 

ERROR 

A  DUPLICATE  POST  NODE  HAS  DEEM  FOUND .  THIS  IS  A 

FATAL  ERROR. 

21 

ERROR 

MOPE  THAN  ONE  MATE  HAS  SEEN  SPECIFIED  FOR  THE 

SAME  LINK.  THIS  IS  A  FATAL  ERROR. 

22 

ERROR 

A  LINK  USED  AS  A  MATE  IS  UNDEFINED .  THIS  IS  A  FATAL 
EPROR. 

23 

ERROR 

A  NODE  USED  IN  AN  AIRPORT  DEFINITION  IS  UNDEFINED. 

24 

ERROR 

NO  ARRIVAL  CR  DEPARTURE  PROCEDURES  HAVE  BEEN  DEFINED 
FOR  A  NODE  USED  IN  AN  AIR PORT  DEFINITION. 

25 

EPRCR 

A  PLAN  USED  IN  DEFINING  ARRIVAL  CR  DEPARTURE 
PROCEDURES  FOR  AN  AIRPORT  IS  UNDEFINED. 

26 

ERROR 

AN  APPIVAL  PROCEDURE  USED  IN  AN  AIRPORT  DEFINITION 

IS  UNDEFINED. 

27 

EPROR 

A  DEPARTURE  PROCEDURE  USED  IN  All  AIRPORT  DEFINITION 

IS  UNDEFINED. 

26 

WARNING 

A  PLAN  USED  IN  DEFINING  ROUTE  SEPARATIONS  IS 
UNDEFINED. 

29 

WARNING 

NOT  ENOUGH  TIME  OR  DISTANCE  DATA  HAS  BEEN  FOUND  IN 

A  FRCCEQL'RE  DEFINITION.  THE  REMAINING  DATA  POSITIONS 
IS  FILLED  WITH  DEFAULT  DATA. 

30 

WARNING 

TOO  MUCH  TIME  CR  DISTANCE  OATA  HAS  BEEN  FOUND  IN 

A  PROCEDURE  DEFINITION.  THE  EXCESS  DATA  IS  IGNORED. 

31 

WARNING 

AN  AIRCRAFT  TYPE  USED  IN  A  PROCEDURE  DEFINITION  IS 
UNDEFINED. 

32 

EPROR 

A  DUPLICATE  FLOWPOST  HAS  BEEN  FOUND.  THIS  IS  A 

FATAL  EPPCR. 

33 

ERROR 

THE  NUMBER  OF  TIME  AND  DISTANCE  ELEMENT  111  A 

PROCEDURE  DEFINITION  IS  NOT  DIVISIBLE  BY  2 .  NO 

MORE  FRCCEOURE  INPUT  IS  READ,  AND  NO  PROCEDURES  ARE 
DEFINED.  TIIIG  MAY  GIVE  PISE  TO  EPFCRS  26  AND  27. 

34 

WARNING 

A  FLCHRCST  NODE  IS  UNDEFINED.  NO  FLOW  CONTROL  IS 
PERFORMED  AT  ANT  F LONMETLR  ASSOCIATED  WITH 

THIS  FLCNPOST. 

35 

WARNING 

A  FLOWMETER  NODE  IS  UNDEFINED.  NO  ACTION  IS  TAKEN. 

36 

WARNING 

A  ROUTE  SPECIFIED  AT  A  FLOWMETER  NODE  IS  UNOEFINEO. 

NO  ACTION  IS  TAKEN. 

37 

WARNING 

A  ROUTE  SPECIFIED  AT  A  FLOWMETER  NODE  DOES  NOT  BEGIN 
AT  THIS  NODE.  NO  ACTION  IS  TAKEN. 

38 

ERROR 

A  ROUTE  HAS  EEEII  SPECIFIED  FOR  MORE  THAN  ONE 

FLOWMETER.  TNI3  IS  A  FATAL  ERROR. 

39 

WARNING 

THE  PLAN  FIX  NODE  OCES  NOT  EXIST.  THE  PARAMETER 

IS  NOT  SET  FOR  THAT  ROUTE. 
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Table  3 


SAMPLE  SIMULATION  LOG  OUTPUT 


TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 

TIME 


-  *»i ; 
•  «i; 
.41; 
.4i; 
.41; 

.41; 

.41; 

.41; 

.41; 

.41; 

.41; 

.41; 

.41; 

.42; 

.42; 

.42; 

.42; 

.42; 

.42; 

.42; 

.42; 

.42; 

.42; 


.42 
.42 
.43 
.43 
.43 
.43 
.43 
.43 
.43 
.43 
.43 
•  m3 
.43 
.43 
.43 
.43 
.43 


C  '  AIRCRAFT  ON  ROUTE  16' ARRIVED  AT  NODE  35 
NOOE  35  NOLDCHECK 

AT  NODE  35 i  NEW  LINK  49,  NEW  NOOE  36 
C  AIRCRAFT  CN  ROUTE  16  IN  NCDE.OEP  AT  35 

(NOMFIT)  C  PLACED  BETWEEN  C  AND 

SPEED  250.0.  TOA  .47,  VECTC°DE LAY  0. 

(McTERCCN)  C  PLACED  IN  METERING  AT  NODE  39  WITH 
METERTIME  .47 
(PAIRCONTPOL) 

DEPARTURE  AT  NODE  33  FOR  NODE  35 
NODE  35  MOVECKECK 

C  AIRCRAFT  CN  ROUTE  16  IN  NODE .DEP  AT  34 

(NOMFIT)  C  PLACED  BETWEEN  C  AND 

SPEED  250.0,  TOA  .47,  VECTORDELAY  0. 

(METERCOH)  C  PLACED  IN  METERING  AT  NODE  39  WITH 
METERTIME  .53 

DEPARTURE  AT  NODE  34  FOR  NODE  35 
C  AIRCRAFT  ON  ROUTE  1  ARRIVED  AT  NODE  15 

C  AIRCRAFT  REMOVED  FRCM  SCUTE  1  AT  NODE  15 

C  AIRCRAFT  ON  ROUTE  11  ARRIVED  AT  NODE  2 

AIRCRAFT  C  LANDING  AT  NODE  2 

C  AIRCRAFT  REMOVED  FROM  ROUTE  11  AT  NODE  2 
NEXT  DEPARTURE  AT  AIRPORT  SFO  IS  BY  AIPCRAFT  C  ON 
ROUTE  2  USING  PROCEDURE  3 

C  AIRCRAFT  ON  ROUTE  16  APRIVED  AT  NODE  I 

AIRCRAFT  C  LANDING  AT  NODE  1 

C  AIRCRAFT  REMOVED  FROM  ROUTE  lo  AT  NODE  1 

NEXT  DEPARTURE  AT  AIRPORT  $FO  IS  BY  AIRCRAFT  C  ON 
ROUTE  2  USING  PROCEDURE  3  AT  TIME  .43 

C  AIRCRAFT  CN  ROUTE  10  ARRIVED  AT  NODE  924 

C  AIRCRAFT  REMOVED  FRCM  ROUTE  10  AT  NODE  R24 

D  AIRCRAFT  CN  ROUTE  11  ARRIVED  AT  NODE  37 

NODE  37  HOLCCHECK 

AT  NODE  37;  NEW  LINK  51,  NEW  NODE  2 
D  „!°CR AFT  CN  ROUTE  11  IN  NCDE.OEP  AT  37 

SPEED  TO A  .50,  VECTORDELAY  0. 

( PAIRCONTPOL I 

DEPARTURE  at  >.CCE  3  7  FOR  NODE  2 
C  AIFCRAFT  CN  ROUTE  lo  ARRIVED  AT  NODE  36 
NOOE  36  HOLDC.'-ECK 

AT  NODE  3>i  NEW  LINK  50,  NEW  NODE  1 
C  AIPCRAFT  CN  ROUTE  16  IN  NCDE.OEP  AT  36 


SPEEO  I*.0.0, 

TOA 

.50,  VECTORDELAY 

0. 

( PAIRCONTPOL 
RESET  C  ; 

1 

SPEED 

134.6,  TOA  .50, 

VECDE  LAY  0. 

,  METTIME 

DEPARTURE  AT 

NOOE 

36  FOR  NODE  1 
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Table  3  (Concluded) 


time 

.89 

TIME 

.89 

TIME 

.89 

TIME 

.09 

TIME 

.89 

TIME 

.89 

TIME 

.89 

time 

.69 

TIME 

.89 

TIME 

.89 

TIME 

.89 

TIME 

.69 

TIME 

.89 

TIME 

.89 

TIME 

.39 

TIME 

.89 

TIME 

.89 

TIME 

.89 

TIME  .09; 

TIME  .90; 
TIME  . 90 ; 
TIME  .90; 
TIME  .901 
TIME  .90; 
TIME  . 90 ; 

_TIKE  .90; 
TIME  .90; 


C  AIRCRAFT  INJECTED  ON  RpilTE  17  AT  NODE  45 

NCDE  45  HOLDCHECK 

AT  NODE  45!  NEW  LINK  57,  NEW  NODE  46 
C  AIRCRAFT  C'l  ROUTE  17  IN  NODE .DEP  AT  45 

(EMPTY)  SPEED  050.0,  TOA  .95,  7ECTCRDELAY  0. 
(MFTERCCN)  C  PLACED  IN  METEPINO  AT  NODE  50  WITH 
METERTIME  .99 

DEPARTURE  AT  NODE  45  FOR  NODE  46 
C  AIRCRAFT  INJECTED  ON  ROUTE  9  AT  NODE  12 

NODE  12  HOLDCHECK 

AT  NOOE  12;  NEW  LINK  21,  NEW  NODE  23 
C  AIRCRAFT  ON  ROUTE  9  IN  NCDE. DEP  AT  12 

(EMPTY)  SPEED  200.0,  TOA  .90,  VECTCRDE LAY  0. 
DEPARTURE  AT  NCDE  12  FOR  NODE  23 
AIPCRAFT  C  T AKINS  OFF  FROM  AIRPORT  SFO  ON 

ROUTE  2  US INS  PROCEDURE  3 

NEXT  DEPARTURE  AT  AIRPORT  SFO  IS  BY  AIRCRAFT  3  ON 
ROUTE  3  USIN' 3  PPOCEDL'PE  4  AT  TIME  .69 

AIRCRAFT  B  TAKING  OFF  FROM  AIRPORT  SFO  ON 
ROUTE  3  US  INS  PPOCEDL'PE  4 

NEXT  DEPARTURE  AT  AIRPORT  SFO  IS  BY  AIRCRAFT  C  ON 
ROUTE  2  USD'S  PROCEDURE  3 

( PRCCBLOCK )  AIRCRAFT  D  IS  NOW  WITHIN  2.00  MI. 

OF  AIRFORT  SFO  .  PROCEDURES  BEING  SLOCKED  APE-' 

3 

4 

5 

6 

NEXT  DEPARTURE  AT  AIRPORT  SFO  IS  BT  AIRCRAFT  C  ON 
ROUTE  2  USING  FPCCEOURE  3 

C  AIRCRAFT  INJECTED  ON  ROUTE  IS  AT  NODE  3B 
NODE  38  HOLDCHECK 

AT  NOOE  33;  NEW  LINX  52.  NEW  NODE  39 
C  AIRCRAFT  ON  ROUTE  18  IN  NODE. DEP  AT  38 
( EMFTY )  SPEED  250.0,  TOA  .96,  VCCTCPDELAY  0. 
(METERCON)  C  PLACED  IN  METERING  AT  NODE  50  WITH 
METERTIME  1.03 

DEPARTURE  AT  NODE  38  FOR  NODE  39 
(SETFLOWS) 


NODE 

25 

SEPARATION 

CI5TANCE 

10.00 

NODE 

£6 

SEPARATION 

distance 

5.00 

NODE 

£7 

SEPARATION 

distance 

5.00 

NODE 

30 

SEPARATION 

DISTANCE 

25.00 

NOOE 

32 

SEPARATION 

DISTANCE 

25.00 

NODE 

34 

SEPARATION 

OISTANCE 

5.00 
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Table  4 


SAMPLE  SIMULATION  REPORT 


DELAY 

AND  TRAVEL 

TIME  STATISTICS  (IN  MINUTES): 

ROUTE 

NUMBER  OF 

AVERAGE 

AVERAGE 

TOTAL 

HUMBER 

AIRCRAFT 

OE  LAY 

TRAVEL  TIME 

DELAY 

1 

17 

19.36 

24.59 

329.04 

2 

9 

22.62 

27.71 

203.53 

3 

6 

10.68 

17.01 

65.25 

4 

6 

16.59 

22.46 

132.71 

5 

4 

.52 

5.36 

2.08 

6 

1 

0. 

3.10 

0. 

7 

1 

0. 

7.70 

0. 

8 

1 

2.37 

9.80 

2.37 

9 

2 

0. 

3.37 

0. 

10 

2 

0. 

3.25 

0. 

11 

20 

2.00 

17.47 

40.04 

12 

3 

.28 

16.28 

.83 

13 

3 

2.34 

18.08 

7.02 

14 

8 

3.28 

19.80 

26.27 

15 

1 

1.22 

12.70 

1.22 

16 

14 

5.77 

17.93 

80.72 

17 

5 

.90 

14.90 

4.50 

18 

2 

0. 

15.75 

0. 

19 

2 

0. 

15.92 

0. 

20 

3 

0. 

16.96 

0. 

21 

2 

0. 

20.33 

0. 

22 

3 

.04 

11.30 

.12 

23 

3 

0. 

12.54 

0. 

TOTALS 

!  120 

7.46 

18.17 

895.74 

TOTAL 

TRAVEL  TIME 


416.05 

249.42 
102.09 
179.64 

21.43 
3.10 
7.70 
9.60 
6.75 
6.49 

349.39 

48.83 
54.23 

156.43 
12.70 

251.75 

74.43 
31.50 

31.83 
50.87 
40.66 
33.91 
37.61 


2180.68 
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c. 


Simulation  Reports 


The  simulation  reports  provide  delay  and  travel  time  statistics  for 
various  periods  of  the  simulation.  An  example  of  a  simulation  report  is 
shown  in  Table  4.  Average  delay  and  travel  time  per  aircraft  as  well  as 
total  dealy  and  travel  time  are  shown  by  route  as  -well  as  for  the  overall 
system.  Delay  and  travel  times  for  departure  routes  include  time  spent 
by  aircraft  on  the  ground  awaiting  departure  clearance. 

The  frequency  of  simulation  reports  is  controlled  by  TIMING  input 
data.  The  user  may  choose  to  receive  a  simulation  report  for  the  seed 
period  of  the  simulation.  Simulation  reports  may  also  be  obtained 
periodically  during  the  simulation  to  show  periodic  results.  A  simula¬ 
tion  report  is  always  obtained  at  the  end  of  the  simulation  giving 
cumulative  results  for  the  entire  simulation  excluding  the  seed  period. 

D.  Additional  Simulation  Results 

Other  potentially  useful  information  within  the  AADM  program  is 
readily  available  for  printing.  Examples  of  such  information  are  delay 
and  travel  time  for  individual  aircraft,  departure  ground  delay  versus 
airborne  delay,  and  delay  on  an  airport-by-airport  basis. 

The  SIMSCRIPT  language  is  designed  to  facilitate  the  gathering  of  a 
wide  variety  of  statistics.  Minimum  effort  is  entailed  in  gathering  and 
printing  statistics  such  as  sums,  means,  variances,  maximums,  and  mini- 
mums  of  quantities  of  interest  in  AADM. 
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V  SAMPLE  APPLICATION 


The  Oakland  Bay  TRACON  airspace  and  chree  airports  at  San  Francisco 
(SFO) ,  Oakland  (OAK),  and  San  Jose  (SJC)  can  be  used  to  demonstrate  the 
application  of  AADM.  This  demonstration,  which  is  described  in  this  sec¬ 
tion,  is  intended  as  an  illustration  of  AADM's  use  and  is  not  a  fully 
calibrated  depiction  of  the  traffic  operation  under  study.  The  demonstra¬ 
tion  is  a  simplified  replication  of  the  airport  and  airspace  system  based 
on  data  collected  from  the  TRACON  and  tower  facilities.  Travel  time  and 
delay  statistics  are  presented  below  to  exemplify  the  outputs  obtainable 
from  an  AADM  simulation;  they  do  not  represent  empirical  measurements 
of  traffic  operations. 

A-  System  Description 

Although  a  variety  of  terminal  traffic  plans  are  employed  in  the 
subject  airport  and  airspace  system  to  service  different  prevailing  wind 
conditions,  the  one  most  frequently  used  is  the  West  Plan.  This  plan's 
major  arrival  and  departure  routings  to  and  from  the  three  airports  are 
shown  in  Figures  13  and  14,  which  also  show  the  link  (solid  and  dashed 
lines)  and  node  (dots)  representation  used  in  the  AADM  simulation. 

With  reference  to  Figure  13,  inbound  routings  from  the  northeast  to 
SFO  actually  overlay  those  to  OAK,  but  as  separate  altitudes.  These 
routes  are  shown  as  noncoincidental  in  plan  view  for  graphical  convenience. 
In  general,  arrival  and  departure  routings  do  not  intersect  each  other 
and  arrival  routings  to  one  airport  do  not  intersect  (because  of  geographic 
or  altitude  separations)  arrival  routings  to  the  other  airports.  However, 
some  departure  routings  do  converge  as  indicated  in  Figure  14  for  those 
outbound  routes  from  OAK  that  join  SFO  outbound  traffic. 
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The  multiairport  departure  mergings  are  simulated  by  AADM,  as 


are  the  arrival  traffic  merging  operations.  The  latter  involve  designation 
of  Levels  II  and  III  metering  nodes  at  the  outer  boundary  nodes  of  the  route 
network,  and  designation  of  Levels  II  and  III  post  nodes  at  approach  fixes 
to  the  various  runway  configurations.  SFO,  which  consists  of  two  pairs 
of  crossing  parallel  runways,  has  approach  and  departure  links  specified 
for  each  individual  runway.  The  other  two  airports  are  modeled  as  single 
runways  servicing  IFR  operations.  Other  OAK  and  SJC  runways  used  by  general 
aviation  aircraft  are  not  addressed  in  this  sample  illustration  although 
they  readily  can  be  simulated  within  the  AADM  framework. 

Another  traffic  plan  employed  in  the  subject  system  is  the  Southeast 

t 

Plan.  The  simplified  replication  of  this  plan's  arrival  and  departure 
traffic  routings  as  simulated  by  AADM  are  shown  in  Figures  15  and  16. 

The  links  and  nodes  for  this  plan  do  not  necessarily  coincide  with  those 
of  the  West  Plan,  and  Southeast  Plan  Levels  II  and  III  metering  and  post 
nodes  are  specified  separately  from  those  of  the  West  Plan. 

AADM  was  used  to  dynamically  simulate  a  change  from  the  West  Plan  to 
the  Southeast  Plan  caused  by  a  change  in  wind  direction.  The  simulation 
required  definition  of  transition  links  from  one  plan's  routing  system 
to  that  of  the  other.  Such  transition  links,  which  are  illustrated  in 
Figure  17,  enable  AADM  to  simulate  the  rerouting  of  aircraft  in  the 
airspace  during  the  transition  period. 

Additional  AADM  data  inputs  specify  operational  details  relevant  to 
aircraft  movement,  separation  rules,  link  and  node  attributes,  wind 
conditions,  airport  procedures,  sectorization ,and  the  like.  These  inputs 
are  described  later  in  this  section. 


B.  Results 


A  traffic  sample  was  developed  using  flight  strip  data  from  the  local 
ATC  facilities.  The  sample  described  the  routing  pattern  over  time  for 
120  aircraft  entering  the  subject  system  during  a  one-hour  period  under 
West  Plan  visual  weather  conditions.  The  aircraft,  which  were  either 
arriving  at  or  departing  from  one  of  the  three  airports,  were  classified 
according  tc  four  categories — (A)  small  single-engine,  (B)  small  twin- 
engine,  (,C)  large,  and  (D)  heavy — to  distinguish  speed  characteristics 
and  separation  requirements. 

The  traffic  sample  was  loaded  into  AADM  which  developed  average 
travel  time  and  delay  estimates  for  the  West  Plan  under  various  VFR 
operating  situations  as  shown  in  Table  5.  The  base  case  assumed  a  3 
nautical  mile  minimum  separation  at  the  approach  fixes  and  15  knot  westerly 
wind.  Additional  results  were  obtained  separately  for  the  no  wind  con¬ 
dition,  a  minimum  4  nautical  mile  approach  separation,  a  10  nautical  mile 
restriction  on  all  SFO  departures  to  Los  Angeles,  and  25  and  50  percent 
traffic  increase  assumptions.  Although  the  travel  time  and  delay  results 
vary  according  to  the  assumptions,  an  undelayed  average  travel  time  (i.e., 
the  difference  between  travel  time  and  delay  of  about  10.5  minutes  re¬ 
sults  in  each  case. 

The  AADM  was  used  to  simulate  West  Plan  and  Southeast  Plan  operation 
under  both  IFR  and  VFR  conditions  as  shown  in  Table  6.  The  first  two  rows 
in  Table  6  assume  West  Plan  operations  during  the  ertire  simulation  period, 
while  the  next  pair  of  rows  describe  Southeast  Plan  operations  during 
the  entire  period.  The  last  row  describes  the  results  obtained  by  simu¬ 
lating  a  transition  from  West  Plan  to  Southeast  Plan  operations  during  the 
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Table  5 

WEST  PLAN  SENSITIVITY 


Ave 

Ave 

Travel 

West  Plan  VFR 

Delay 

Time 

Base  Case  W"/15™) 

7.46min 

18. 171 

NO  WIND 

4.67 

14.90 

4 NM  APPROACH  SPACING 

7.42 

18.13 

1QNM  LA  ROUTE  RESTRICTION 

7.46 

18.17 

25 %  TRAFFIC  INCREASE 

13.21 

23.93 

50%  TRAFFIC  INCREASE 

18.48 

29.19 
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simulation  period.  The  travel  time  and  delay  statistics  vary  according 
to  conditions,  but  the  undelayed  travel  time  for  each  of  the  all-Southeast 
IFR  and  VFR  plans  (i.e.,  12.9  minutes)  is  four  minutes  greater  than  that 
of  the  corresponding  West  Plan  operation.  Similarly,  the  undelayed 
travel  time  associated  with  the  VFR  West-to-Southeast  Plan  transition  is 
four  minutes  greater  than  the  all-West  Plan  VFR  operation. 

While  the  actual  magnitude  of  the  data  results  should  not  be  considered 
significant  because  of  the  experiment ial  nature  of  the  input  specifications, 
che  results  do  show  the  capability  of  AADM  to  evaluate  alternative  operating 
scenarios . 

C.  Computer  Processing  Costs 

Table  7  provides  an  indication  of  the  computer  resources  required  by 
an  AADM  simulation  run.  As  can  be  seen,  the  program  cose  only  $4.10  for 
a  single  run  which  included  extensive  application  of  airspace  traffic 
control  Levels  1,  II  and  III,  airport /airspace  interface  and  associated 
input,  output,  and  executive  control  logic  components. 
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Table  7 

COMPUTER  RESOURCES 


CPU  TIME* 

0.09 

MINUTES 

MEMORY  * 

80K 

WORDS 

DISK  I/O* 

854 

ACCESSES 

PRINTER* 

3196 

LINES 

COST 

$4.10 

WEST  PLAN  VFR  CASE  WITH  120  AIRCRAFT  USING  SCIP  IBM  370/168 


r 


D.  Input  Data 

A  listing  of  the  input  data  file  for  the  sample  application  is  pro¬ 
vided  in  Table  8.  The  input  lines  or  card  records  are  numbered  for  the 
purposes  of  reference  (data  were  actually  input  by  terminal  keyboard  entry) . 
The  first  16  cards  are  job  control  language  cards  and  are  not  included  in 
Table  8.  The  data  shown  include  all  information  needed  to  exercise  all  of 
the  plans  considered  in  this  demonstration;  but  PLAN  and  WIND  event  cards 
must  be  added  between  input  cards  498  and  499  to  define  the  case  being 
considered . 

The  input  data  format  is  free  form.  Therefore,  in  general,  the 
data  entries  do  not  have  to  be  placed  in  specific  card  columns.  However, 
there  must  be  at  least  one  blank  space  between  each  data  entry.  Also, 
the  keywords  and  certain  data  entries  must  begin  in  column  1.  In  the 
following  sections  of  this  chapter,  descriptions  of  the  entries  for  each 
data  category  in  Table  8  are  provided,  together  with  any  restrictions 
on  their  positions  on  the  input  cards. 

1.  TRACE 

This  keyword  is  followed  by  data  which  specify  the  information  to 
be  printed  in  the  simulation  log.  The  word  TRACE  is  followed  by  pairs 
of  entries;  the  first  entry  is  a  number  designating  a  type  of  information 
in  the  simulation  log  and  the  second  number  is  set  equal  to  one  if  the 
type  of  information  is  to  be  printed  in  the  simulation  log  and  zero  if 
not.  Any  type  of  information  not  mentioned  is  not  printed.  Thus,  the 
data  on  card  17  specify  that  information  of  types  1  and  2  is  to  be  printed 
in  the  simulation  log.  The  types  of  information  are  as  shown  in  the  fol¬ 
lowing  tabulation: 
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Type 

1 

2 

3 

4,5,6 

7 

8 
9 

10 


Actions  Described  in  Simulation  Log _ 

Aircraft  entering  the  airspace 

Aircraft  exiting  the  airspace 

Aircraft  holding,  node  arrivals  and  node 
departures 

Level  I  control  (except  paired  aircraft  control) 

Level  II  control 

Paired  aircraft  control 

Landings  and  takeoffs 

Level  III  control 


The  data  on  cards  18  through  109  define  system  nodes.  Each  card  contain 
data  for  one  node.  The  data  entries  in  order  of  input  are: 

•  Identification  number  assigned  to  the  node 
(must  begin  in  column  1). 

•  Altitude  of  the  node  in  feet. 

* 

•  Level  I  arrival  strategy  number. 

•  Initial  value  of  the  in-trail  strategic  separation  distance 
between  aircraft  in  miles. 

•  Maximum  number  of  aircraft  that  can  be  held  at  the  node. 

•  Holding  strategy  number  for  the  node. 

1 —  hold  if  there  is  holding  at  the  next  node  in  the  route. 

2 —  hold  if  the  holding  stack  at  the  next  node  is  full. 

3 —  hold  if  the  number  of  aircraft  in  holding  at  the  next 
node  plus  the  number  approaching  the  node  is  not  less 
than  the  holding  stack  capacity. 


See  Section  IV.E.l.  Only  Strategies  1,  2,  or  3  are  specified  here. 
Strategy  4  is  not  fully  implemented.  Strategies  5  and  6  are  prescribed 
via  link  data  input. 
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Table  8 


LISTING  OF  INPUT  DATA  FOR  THE  SAMPLE  APPLICATION 


17. 

16. 

1*. 

TRACE  1  1 
NODES 

1  0 

2  1 

1 

1 

0 

1 

20. 

2 

0 

1 

1 

0 

1 

21. 

3 

0 

1 

1 

0 

1 

22. 

4 

0 

1 

1 

0 

L 

23. 

5 

0 

1 

1 

0 

1 

24. 

6 

0 

1 

1 

0 

1 

25. 

7 

0 

1 

1 

0 

1 

26. 

6 

0 

1 

1 

0 

1 

27. 

9 

0 

'  1 

1 

0 

1 

26. 

909 

0 

1 

1 

0 

1 

29. 

10 

0 

1 

1 

0 

1 

30. 

910 

0 

1 

1 

0 

1 

31. 

a 

50 

1 

1 

0 

1 

32. 

12 

50 

1 

1 

0 

1 

33. 

13 

4000 

1 

3 

0 

2 

34. 

14 

8000 

3 

5 

0 

2 

35. 

15 

10000 

3 

5 

1 

2 

36. 

16 

10000 

3 

5 

1 

2 

37. 

17 

2000 

1 

3 

0 

2 

36. 

16 

10000 

3 

3 

0 

2 

39. 

19 

11000 

3 

5 

1 

2 

40. 

20 

11000 

3 

5 

1 

2 

41. 

21 

2000 

1 

3 

0 

2 

42. 

22 

10000 

3 

5 

1 

2 

43. 

23 

2000 

1 

3 

0 

2 

44. 

24 

10000 

3 

5 

1 

2 

45. 

924 

10000 

3 

5 

1 

2 

46. 

25 

11000 

3 

5 

0 

1 

47. 

26 

11000 

3 

5 

0 

1 

46. 

27 

11000 

3 

5 

0 

1 

49. 

28 

11000 

3 

3 

1 

2 

50. 

29 

11000 

3 

3 

3 

2 

51. 

30 

11000 

3 

5 

0 

1 

52. 

31 

4000 

3 

3 

3 

2 

53. 

32 

10000 

3 

5 

0 

2 

54. 

33 

6000 

3 

3 

3 

2 

55. 

34 

10000 

3 

5 

0 

* 

«. 

56. 

35 

6000 

3 

3 

3 

2 

57. 

36 

4000 

3 

3 

1 

1 

58. 

37 

4000 

3 

3 

1 

1 

59. 

36 

10000 

3 

5 

0 

1 

60. 

39 

7000 

3 

3 

3 

2 

61. 

40 

10000 

3 

5 

0 

1 

62. 

41 

10000 

3 

5 

0 

1 

63. 

42 

7000 

3 

3 

3 

2 

64. 

43 

7000 

3 

5 

0 

1 

65. 

44 

2000 

3 

3 

3 

2 

66. 

45 

10000 

3 

5 

0 

1 

67. 

46 

6000 

3 

3 

3 

2 

66. 

47 

3500 

3 

3 

1 

1 

69. 

46 

6000 

3 

5 

0 

1 

70. 

49 

6000 

3 

5 

0 

1 

71. 

50 

4000 

3 

5 

3 

1 

72. 

51 

2500 

1 

3 

0 

2 

73. 

52 

2500 

1 

3 

0 

2 

74. 

53 

3000 

1 

3 

0 

2 

75. 

54 

7000 

3 

3 

0 

2 

76. 

55 

6000 

3 

3 

0 

2 

77. 

56 

9000 

3 

5 

1 

2 

78. 

57 

11000 

3 

5 

1 

2 

79. 

56 

10000 

3 

5 

1 

2 

60. 

59 

3000 

1 

3 

0 

2 

61. 

60 

7000 

3 

5 

1 

2 

62. 

41 

11000 

3 

5 

1 

2 

I 
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Table  8  (continued) 


53.  62  10000  3591 

54.  63  6000  3332 

55.  64  5000  3501 

56.  65  6000  3332 

57.  66  4500  3311 

58.  67  9000  3501 

59.  66  7000  3332 

90.  69  10000  3501 

91.  70  5000  3501 

92.  71  8000  3332 

93.  72  600Q  3312 

94.  73  4500'  3  3  11 

95.  74  9000  3501 

96.  75  4000  3  3  3  2 

97.  76  6000  3501 

96.  77  4000  3332 

99.  78  7000  3501 

100.  79  5000  3332 

101.  80  9000  3501 

102.  81  7000  3332 

103.  52  5000  3311 

104.  83  3000  3311 

105.  983  3000  3311 

106.  84  10000  3501 

107.  85  10000  3501 

108.  86  4000  3332 

109.  87  2000  3311 

110.  LINKS 


111. 

9 

3 

13 

100 

029 

1 

0 

0 

4 

3 

0 

112. 

10 

4 

17 

50 

350 

1 

0 

0 

2 

3 

0 

113. 

11 

10 

21 

50 

288 

1 

0 

0 

2 

3 

0 

114. 

12 

910 

21 

50 

288 

1 

0 

0 

2 

3 

0 

115. 

13 

13 

14 

50 

029 

2 

1 

0 

2 

3 

0 

116. 

913 

21 

14 

90 

060 

2 

1 

0 

2 

3 

0 

117. 

14 

21 

17 

60 

200 

2 

1 

0 

3 

3 

0 

118. 

15 

14 

15 

50 

029 

2 

1 

0 

2 

3 

0 

119. 

16 

13 

16 

90 

347 

2 

1 

0 

4 

5 

0 

120. 

17 

17 

18 

130 

200 

2 

1 

0 

5 

5 

0 

121. 

16 

16 

20 

60 

168 

2 

1 

0 

3 

5 

0 

122. 

19 

18 

19 

50 

135 

2 

1 

0 

2 

5 

0 

123. 

20 

21 

22 

60 

330 

2 

1 

0 

3 

5 

0 

124. 

21 

12 

23 

30 

302 

1 

0 

0 

2 

3 

0 

125. 

22 

23 

24 

100 

357 

2 

1 

0 

4 

5 

0 

126. 

23 

23 

924 

100 

121 

2 

1 

0 

4 

5 

0 

127. 

39 

25 

29 

150 

245 

4 

1 

0 

6 

5 

0 

128. 

40 

26 

28 

100 

215 

4 

1 

0 

4 

5 

0 

129. 

41 

27 

28 

120 

162 

4 

1 

0 

5 

5 

0 

130. 

42 

28 

29 

50 

215 

4 

1 

0 

2 

5 

0 

131. 

43 

29 

37 

270 

250 

4 

1 

0 

10 

5 

0 

132. 

44 

30 

31 

360 

120 

4 

1 

0 

13 

5 

0 

133. 

45 

31 

36 

150 

100 

4 

1 

0 

6 

5 

0 

134. 

46 

32 

33 

190 

060 

4 

1 

0 

7 

5 

0 

135. 

47 

33 

36 

100 

020 

4 

1 

0 

4 

5 

0 

136. 

48 

34 

35 

150 

331 

4 

1 

0 

6 

5 

0 

137. 

49 

35 

36 

150 

331 

4 

1 

0 

6 

5 

0 

136. 

50 

36 

1 

100 

281 

3 

0 

1 

4 

3 

51 

139. 

51 

37 

2 

100 

261 

3 

0 

1 

4 

3 

50 

140. 

52 

38 

39 

150 

245 

4 

1 

0 

6 

5 

0 

141. 

53 

40 

42 

100 

229 

4 

1 

0 

4 

5 

0 

142. 

54 

41 

42 

60 

162 

4 

1 

0 

3 

5 

0 

143. 

55 

39 

47 

170 

250 

4 

1 

0 

6 

5 

0 

144. 

56 

42 

47 

230 

229 

4 

1 

0 

8 

S 

0 

145. 

57 

45 

46 

150 

275 

4 

1 

0 

6 

5 

0 

146. 

58 

46 

47 

100 

275 

4 

1 

0 

4 

5 

0 

147. 

59 

43 

44 

200 

110 

4 

1 

0 

7 

5 

0 

148. 

60 

44 

47 

250 

110 

4 

1 

0 

9 

5 

0 

149. 

61 

47 

9 

160 

293 

3 

0 

1 

6 

3 

0 

150. 

62 

48 

50 

150 

333 

4 

1 

0 

6 

5 

0 
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Table  8  (continued) 


Table  8  (continued) 


221. 

222. 

223. 

224. 

225. 

226. 
227. 
226. 

229. 

230. 

231. 

232. 

233. 

234. 

235. 

236. 

237. 
236. 

239. 

240. 

241. 

242. 

243. 

244. 

245. 

246. 

247. 
246. 

249. 

250. 

251. 

252. 

253. 

254. 

255. 

256. 

257. 

258. 

259. 

260. 

261. 

262. 

263. 

264. 

265. 

266. 
267. 
266. 

269. 

270. 

271. 

272. 

273. 

274. 

275. 


15 

32 

33 

36 

1 

;  33 

16 

34 

35 

36 

1 

;  35 

17 

45 

46 

47 

9 

;  46 

16 

38 

39 

47 

9 

;  39 

19 

40 

42 

47 

9 

;  42 

20 

41 

42 

47 

9 

;  42 

21 

43 

44 

47 

9 

;  44 

22 

46 

SO 

11  ; 

50  ; 

23 

49 

50 

li  ; 

50  ; 

41 

25 

29 

36 

l 

> 

42 

26 

28 

29 

36 

1 

* 

43 

27 

29 

29 

36 

l 

; 

51 

2 

52 

54 

55 

57 

» 

1 

52 

2 

52 

54 

55 

57 

» 

> 

53 

1 

51 

56  ; 

; 

54 

1 

51 

54 

56 

t 

55 

909 

53 

55 

57 

» 

56 

909 

S3 

55 

57 

l 

57 

9 

53 

54 

56 

t 

56 

9 

53 

54 

56 

» 

59 

11 

59 

61  ; 

1 

60 

11 

59 

60  ; 

» 

61 

62 

63 

66 

3 

;  25 

29  63  ;  ; 

62 

62 

63 

66 

3 

; 

26 

28  29  63 

» 

63 

64 

65 

66 

3 

; 

27 

28  29  63  ; 

l 

64 

67 

66 

72 

73 

4 

30 

31  72  ; 

72  i 

65 

70 

71 

72 

73 

4 

32 

33  71 

72 

66 

69 

71 

72 

73 

4 

34 

35  71  ; 

72  ; 

67 

60 

81 

62 

983 

10 

66 

74 

75 

77 

63 

10 

45 

46  75  ; 

38 

39  75 

69 

74 

75 

77 

63 

10 

40 

42  75  ; 

t 

70 

76 

77 

63 

10 

» 

41 

42  75  77  ! 

» 

71 

78 

79 

963 

10 

» 

43 

44  79  ;  ; 

72 

64 

66 

67 

12 

» 

48 

50  66  ;  ; 

73 

65 

66 

87 

12 

* 

49 

50  66  ;  > 

64 

67 

66 

72 

66 

3 

30 

31  72 

i 

i 

65 

70 

71 

72 

66 

3 

32 

33  71 

» 

i 

66 

69 

71 

72 

66 

3 

34 

35  71 

» 

» 

SECTORS 

1 

7 

9 

11 

13 

913 

15 

16 

20 

59  24 

27 

28 

34 

35 

2 

9 

10 

12 

14 

17 

16 

19 

25 

26  29 

30 

31 

33 

3 

9 

44 

46 

46 

70 

71 

72 

73 

74  62 

64 

65 

104 

105 

106 

4 

9 

45 

47 

49 

75 

102 

5 

7 

39 

40 

41 

42 

52 

53 

54 

57  66 

67 

66 

78 

79 

103 

107 

106 

109 

110 

6 

9 

43 

69 

101 

7 

6 

23 

60 

81 

6 

6 

55 

56 

56 

60 

63 

66 

9 

6 

62 

63 

36 

37 

36 

69 

90 

91  111 

10 

6 

21 

22 

11 

6 

50 

51 

76 

77 

12 

6 

61 

87 

66 

276. 

13 

6 

64 

277. 

AIRCRAFT 

278. 

1  A 

200 

250 

279. 

2  8 

200 

250 

260. 

3  C 

200 

250 

261. 

4  D 

200 

250 

92 

100  250  ;  220  250 
120  250  ;  220  250 
140  250  220  250 
140  250  i  220  250 


120 

250 

180 

220 

140 

250 

160 

220 

160 

250 

160 

220 

160 

250 

160 

220 

60  160  ;  3  3  4  6 
100  160  i  3  3  4  6 
120  160  i  3  3  3  5 
120  160  ;  3  3  3  4 


i 
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282. 

PLANS 

283. 

1 

1 

51 

51 

284. 

2 

2 

52 

52 

285. 

3 

3 

53 

53 

286. 

4 

4 

54 

54 

287. 

5 

5 

55 

55 

288. 

6 

6 

56 

56 

289. 

7 

7 

57 

57 

290. 

8 

8 

58  . 

58 

291. 

9 

9 

59 

59 

292. 

10 

10 

60 

60 

293. 

11 

41 

61 

61 

294. 

12 

42 

62 

62 

295. 

13 

43 

63 

63 

296. 

14 

14 

64 

84 

297. 

15 

15 

65 

85 

298. 

16 

16 

66 

86 

299. 

17 

17 

67 

67 

300. 

18 

18 

68 

68 

301. 

19 

19 

69 

69 

302. 

20 

20 

70 

70 

303. 

21 

21 

71 

71 

304. 

22 

22 

72 

72 

305. 

23 

23 

73 

73 

306. 

AIRPORTS 

307. 

1  SFO 

1 

2 

3  4 

308. 

1 

1 

» 

309. 

2 

1 

1 

310. 

3 

; 

10 

» 

311. 

4 

i  12 

» 

» 

312. 

1 

2 

» 

313. 

2 

2 

i 

314. 

3 

» 

9 

315. 

4 

> 

11 

i 

! 

316. 

1 

3 

317. 

2 

5 

318. 

3 

8 

► 

319. 

4 

8 

» 

320. 

1 

» 

321. 

2 

; 

322. 

3 

7 

► 

323. 

4 

7 

• 

324. 

2  OAK 

9 

909  1< 

325. 

1 

13 

i 

326. 

2 

13 

> 

327. 

3 

;  17 

328. 

4 

;  17 

i 

329. 

3 

;  is 

330. 

4 

;  is 

» 

331. 

1 

i 

14 

332. 

2 

* 

14 

333. 

3 

16 

» 

334. 

4 

16 

t 

• 

335. 

1 

i 

15 

336. 

2 

» 

15 

» 

337. 

3  SJC 

11 

12  ; 

338. 

1 

19 

* 

339. 

2 

19 

i 

340. 

3 

» 

22 

341. 

4 

! 

22 

J 

342. 

1 

• 

20 

343. 

2 

» 

20 

344. 

3 

21 

1 

345. 

4 

21 

» 

* 
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Table  8  (continued) 


346 . 

PROCEDURES 

347. 

1 

1 

40 

0 

40 

40  40 

40 

0 

0 

2 

2  2  2 

348. 

2 

50 

0 

50 

50  50 

50 

0 

0 

2 

2  2  2 

349. 

3 

60 

0 

SO 

55  50 

55 

0 

0 

2 

2  2  2 

350. 

4 

75 

0 

50 

55  50 

55 

0 

0 

2 

2  2  2 

351. 

2 

1 

0 

40 

40 

40  40 

40 

0 

0 

2 

2  2  2 

352. 

2 

0 

50 

50 

50  50 

50 

0 

0 

2 

2  2  2 

353. 

3 

0 

60 

50 

55  50 

55 

0 

0 

2 

2  2  2 

354. 

4 

0 

75 

50 

55'  50 

55 

0 

0 

2 

2  2  2 

355. 

3 

1 

35 

40 

55 

0  0 

0 

0 

0 

0 

0  0  0 

356. 

2 

35 

40 

55 

0  0 

0 

0 

0 

0 

0  0  0 

357. 

3 

35 

40 

50 

0  0 

0 

0 

0 

0 

0  0  0 

356. 

4 

35 

40 

50 

50  0 

0 

0 

0 

2 

2  0  0 

359. 

4 

1 

30 

35 

0 

50  0 

0 

0 

0 

0 

0  0  0 

360. 

2 

30 

35 

0 

50  0 

0 

0 

0 

0 

0  0  0 

361. 

3 

30 

35 

0 

45  0 

0 

0 

0 

0 

0  0  0 

362. 

4 

30 

35 

50 

45  0 

0 

0 

0 

<3 

2  0  0 

363. 

5 

1 

35 

40 

0 

0  55 

55 

0 

0 

0 

0  0  0 

364. 

2 

35 

40 

0 

0  55 

55 

0 

0 

0 

0  0  0 

365. 

3 

35 

40 

0 

0  50 

50 

0 

0 

0 

0  0  0 

366. 

4 

35 

40 

0 

0  50 

50 

0 

0 

0 

0  2  2 

367. 

6 

1 

30 

35 

0 

0  50 

50 

0 

0 

0 

0  0  0 

366. 

2 

30 

35 

0 

0  50 

50 

0 

0 

0 

0  0  0 

369. 

3 

30 

35 

0 

0  45 

45 

0 

0 

0 

0  0  0 

370. 

4 

30 

35 

0 

0  45 

45 

0 

0 

0 

0  2  2 

371. 

7 

1 

35 

0 

35 

35  35 

35 

0 

0 

3 

3  3  3 

372. 

2 

50 

0 

35 

40  35 

40 

0 

0 

3 

3  3  3 

373. 

3 

65 

0 

30 

35  30 

35 

0 

0 

3 

3  3  3 

374. 

4 

65 

0 

30 

35  30 

35 

0 

0 

3 

3  3  3 

375. 

8 

1 

0 

40 

40 

40  40 

40 

0 

0 

3 

3  3  3 

376. 

2 

0 

55 

40 

45  40 

45 

0 

0 

3 

3  3  3 

377. 

3 

0 

60 

35 

40  35 

40 

0 

0 

3 

3  3  3 

378. 

4 

0 

75 

35 

40  35 

40 

0 

0 

3 

3  3  3 

379. 

9 

1 

40 

45 

70 

0  0 

0 

0 

0 

0 

0  0  0 

360. 

2 

40 

45 

70 

0  0 

0 

0 

0 

0 

0  0  0 

381. 

3 

40 

45 

60 

0  0 

0 

0 

0 

0 

0  0  0 

362. 

4 

40 

45 

60 

60  0 

0 

0 

0 

2 

2  0  0 

363. 

1C 

1 

;  35 

40 

0 

65  0 

0 

0 

0 

0  0  0  0 

384. 

2 

;  35 

40 

0 

65  0 

0 

0 

0 

0  0  0  0 

365. 

3 

;  35 

40 

0 

55  0 

0 

0 

0 

0  0  0  0 

386. 

4 

i  35 

40 

55 

55  0 

0 

0 

0 

2  2  0  0 

367. 

11 

1 

;  40 

45 

0 

0  70 

70 

0 

0 

0  0  0  0 

386. 

2 

;  40 

45 

0 

0  70 

70 

0 

0 

0  0  0  0 

369. 

3 

;  40 

45 

0 

0  60 

60 

0 

0 

9  0  0  0 

390. 

4 

;  40 

45 

0 

0  60 

60 

0 

0 

0  0  2  2 

391. 

12 

1 

;  35 

40 

0 

0  65 

65 

0 

0 

0  0  0  0 

392. 

2 

;  35 

40 

0 

0  65 

65 

0 

0 

0  0  0  0 

393. 

3 

;  35 

40 

0 

0  55 

55 

0 

9 

0  0  0  0 

394. 

4 

;  35 

40 

0 

0  55 

55 

0 

0 

9  0  2  2 

395. 

13 

1 

;  55 

55 

55 

0  3  3 

396. 

2 

;  45 

45 

45 

0  3  3 

397. 

3 

;  55 

55 

55 

0  3  3 

398. 

4 

;  65 

65 

65 

0  3  3 

399. 

14 

1 

;  65 

65 

65 

0  0  0 

400. 

2 

i  65 

65 

65 

0  0  0 

401. 

3 

;  55 

55 

55 

0  0  0 

402. 

4 

;  55 

55 

55 

0  2  2 

403. 

IS 

1 

;  65 

65 

65 

0  0  0 

404. 

2 

;  65 

65 

65 

0  0  0 

405. 

3 

i  55 

55 

55 

0  0  0 

406. 

4 

;  55 

55 

55 

0  2  2 

407. 

16 

1 

;  75 

75 

75 

0  3  3 

406. 

2 

;  75 

75 

75 

0  3  3 

409. 

3 

1  65 

65 

65 

0  3  3 

410. 

4 

;  65 

65 

65 

0  3  3 

8b 


Table  8  (continued) 


411. 

17 

1 

65 

65 

65  0 

0 

o  ; 

412. 

2 

65 

65 

65  0 

0 

o  ; 

413. 

3 

55 

55 

55  0 

0 

o  ; 

414. 

4 

55  55 

55  0 

2 

2  ; 

415. 

18 

1 

65 

65 

65  0 

0 

o  ; 

416. 

2 

65 

65 

65  0 

0 

o  ; 

417. 

3 

55 

55 

55  0 

0 

o  ; 

418. 

4 

55 

55 

55  0 

2 

2  ; 

419. 

19 

1 

45 

45 

0 

3 

420. 

2 

45 

45 

0 

3 

421. 

3 

60 

60 

0 

3 

422. 

4 

70 

70 

0 

3 

423. 

20 

1 

60 

60 

0 

0 

424. 

2 

60 

60 

0 

0 

425. 

3 

50 

50 

0 

0 

426. 

4 

50 

50 

0 

2 

427. 

21 

1 

40 

40 

0 

3 

420. 

2 

65 

65 

0 

3 

429. 

3 

55 

55 

0 

3 

430. 

4 

65 

65 

0 

3 

431. 

22 

1 

60 

60 

0 

0 

432. 

2 

60 

60 

0 

0 

433. 

3 

55 

50 

0 

0 

434. 

4 

SO 

50 

0 

2 

435.  METERING 

436.  37  1 

437.  25  11  ! 

438.  26  12  ; 

439.  27  13  I 

440.  36  1 

441.  30  14  i 

442.  32  15 

443.  34  16  ! 

444.  47  1 

445.  45  17  ; 

446.  38  18  > 

447.  40  19  ; 

448.  41  20  ; 

449.  43  21  ; 

450 .  66  1 

451.  62  61  62  i 

452.  64  63 

453.  73  1 

454.  67  64  ; 

455.  70  65  i 

456.  69  66  i 

457.  983  1 

458.  80  67  ; 

459.  78  71  ; 

460.  53  1 

461.  74  68  69  ; 

462.  76  70  ; 

463.  FLOWS  0.1 

464.  2  120 

465.  25  250  5  0  5  25  11  ; 

466.  26  250  5  0  5  25  12  > 

467.  27  250  5  0  5  25  13  ; 

468.  1  120 

469.  30  250  5  0  5  25  14  ; 

470.  32  250  5  0  5  25  15  ; 

471.  34  250  5  0  5  25  16  ; 
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Table  8  (.concluded) 


472. 

<*73. 

474. 

475. 

476. 

477. 
47#. 
474. 
460. 
481. 

462 . 

463. 

464. 

465. 

466. 

467. 
486. 
469. 

490. 

491. 

492. 

493. 

494. 

495. 
497. 
49#. 

499. 

500. 
SOX. 

502. 

503. 

504. 

505. 

506. 

507. 

508. 

509. 
5X0. 
SIX. 
5X2. 
5X3. 
5X4. 
5X5. 
5X6. 
517. 
5X8. 
5X9. 

520. 

521. 

522. 

523. 

524. 

525. 

526. 

527. 

528. 
525. 

530. 

S3X. 


9  120 

45  250  5  0 
38  250  5  0 

40  250  5  0 

41  250  5  0 
43  250  5:0 

11  120 

48  250  5  0 

49  250  5  0 

3  120 

62  250  5  0 
64  250  5  0 

4  120 

67  250  5  0 
70  250  5  0 
69  250  5  0 
10  120 
80  250  5  0 
78  250  5  0 
74  250  5  0 
76  250  5  0 
12  120 

84  2S0  5  0 

85  250  5  0 
TIMING  2.0 
GO 

MULTDEP  .0 
MULTOEP  .o 
*JLTOEP  .  o 
MULTOEP  .0 
MULTOEP  . 0 
MULTOEP  . 9 
MULTOEP  .0 
MULTOEP  .9 
MULTDEP  .0 
MULTOEP  .0 
MULTDEP  .0 
MULTOEP  .0 
MULTOEP  .0 
MULTOEP  .0 
MULTDEP  .0 
MULTARR  .0 
MULTARR  .0 
MULTARR  . o 
MULTARR  .0 
MULTARR  .o 
MULTARR  . o 
WJLTARR  .o 
MULTARR  .  o 

MULTARR  .  o 

MULTARR  .  o 

MULTARR  .  o 

MULTARR  .0 

HJLTARR  .  0 

MULTARR  .0  j 

MULTARR  . 0  j 

MULTARR  .0  j 

MULTARR  .Q  j 

MULTARR  .0  > 


I  5  25  17 
I  5  25  18 
I  5  25  19 
l  5  25  20 
5  25  21 

5  25  22 
5  25  23 

5  25  61  i 
5  25  63 

5  25  64 
5  25  65 
5  25  66 

5  25  67  ; 
5  25  71  ; 
5  25  68  6 
5  25  70  ; 

5  25  72  ; 
5  25  73  ; 

0.0  .X 
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3. 


LINKS 


The  data  on  cards  110  through  205  define  the  links.  Each  card 
contains  data  for  one  link.  The  data  entries  in  order  are: 

•  Identification  number  assigned  to  the  link 
(must  begin  in  column  1) 

•  Number  of  the  initial  node  of  the  link. 

•  Number  of  the  terminal  node  of  the  link. 

•  Length  of  the  link  in  tens  of  miles. 

•  Average  heading  of  the  link  in  degrees. 

•  Type  number  of  the  link. 

•  Overtake  flag 

1 — no  overtaking  allowed. 

0 — overtaking  allowed. 

•  Waketurbulence  flag 

1 — try  to  avoid  having  light  aircraft  trailing  heavy  aircraft. 
0 — no  light/heavv  aircraft  sequencing  necessary. 

•  Maximum  number  of  aircraft  allowed  on  the  link. 

•  Maximum  delay  in  minutes  that  can  be  absorbed  by  vectoring  an 
aircraft  on  the  link. 

•  Number  of  the  mate  link, 
i .  ROUTES 


Tne  data  on  cards  206  through  258  define  system  routes.  Each  card 
contains  data  for  one  route.  The  data  entries  in  order  are: 

•  Identification  number  assigned  to  the  route  (must  begin  in  column  1) 

•  Route  departure  separation  distance  restriction  (in  miles),  if 
any  (the  default  value  for  this  parameter  is  entered  immediately 
after  the  keywor d  "ROUTES"). 


•  List  of  node  numbers  defining  the  primary  route,  terminated  bv 
- 

a  *  • 

•  Lists  of  nodes  defining  "transition"  routes  terminating  on  the 
primary  route,  each  list  terminated  by  a 

•  A  node,  if  any,  on  the  primary  route  beyond  which  aircraft  on  the 
route  are  not  to  be  rerouted  in  the  event  of  a  plan  change. 
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AD-A090  7fll  SRI  INTERNATIONAL  MENLO  PARK  CA 

AIRPORT  AND  AIRSPACE  DELAY  MODEL  DESCRIPTION. <U> 

OCT  79  JC  BOBICK »  6  J  COULURIS  DOT-FA 77 WA-40 33 

UNCLASSIFIED  FAA-AVP-79-11  NL 


The  data  for  a  single  route  may  be  placed  on  more  than  one  card.  However 
column  1  on  all  cards  except  the  first  must  be  left  blank.  This  rule 
holds  in  general  for  the  input . 


5.  SECTORS  ; 

The  data  on  cards  259  through  276  define  the  airspace  sectors.  Data 
for  each  sector  must  begin  in  column  1;  data  on  successive  cards  for  the 
same  sector  must  not  be  placed  in  column  1.  The  data  entries  for  each 
sector  in  order  of  entry  are: 

•  Identification  number  assigned  to  the  sector  (must  begin  in 
column  1) . 

•  Maximum  number  of  aircraft  allowed  in  the  sector  because  of 
controller  workload  constraints. 

•  List  of  links  in  the  sector. 

6.  AIRCRAFT 

The  data  on  cards  277  through  281  define  speed  and  minimum  separation 
requirements  for  aircraft  of  various  types.  Each  card  contains  data 
for  one  aircraft  type.  The  data  entries  in  order  are: 

•  Aircraft  type  number 

•  Aircraft  type  name 

•  Nominal  speed  in  knots  of  this  type  of  aircraft  on  each  of  the 
types  of  links. 

»»  .  If 

•  Maximum  speed  in  knots  of  this  type  of  aircraft  on  each  of  the 
types  of  links . 


•  Minimum  speed  in  knots  of  this  type  of  aircraft  on  each  of  the 
types  of  links. 


e  Minimum  allowable  separation  distance  in  miles  for  this  type  of 
aircraft  trailing  each  of  the  other  types  of  aircraft. 


In  cases  where  many  types  of  links  and  aircraft  are  defined,  more 
than  one  card  may  be  required  to  input  data  for  a  single  aircraft  type. 


In  this  case,  column  1  of  cards  other  than  the  first  must  be  blank. 

7.  PLANS 

The  data  on  cards  282  through  305  define  the  route  transitions  among 
the  various  plans.  Each  card  contains  data  for  one  route.  The 
data  in  order  of  input  are: 

•  A  specific  route  number. 

•  Number  of  the  route  onto  which  traffic  transitions  from  the 
specified  route  when  changing  to  plan  2. 

•  Repeat  above  entry  for  plan  3,  4,  etc. 

3.  AIRPORTS 


Cards  306  through  345  contain  the  data  defining  the  airports  and 
specifying  the  arrival  and  departure  procedures  to  be  used  in  each  of  the 
airport  plans.  Data  on  cards  307-323  contain  data  for  the  first  airport, 
namely,  San  Francisco  International.  The  data  entries  for  this  first 
airport  are: 

•  Number  assigned  to  the  airport  (must  begin  in  column  1) . 

•  Name  assigned  to  the  airport. 

•  List  of  numbers  of  the  airport/airspace  interface  nodes 
associated  with  this  airport,  terminated  by  a 

•  Plan  number,  followed  by  a  list  of  arrival  procedures  to 

be  used  for  aircraft  arriving  at  the  first  associated 
airport/airspace  interface  node  under  this  plan,  followed 
by  a  then  a  list  of  departure  procedures  to  be  used 

for  aircraft  departing  through  the  first  airport/airspace 
Interface  node  under  this  plan,  followed  by  a  " . 

•  Repeat  the  above  step  for  each  plan  for  the  first 
airport/airspace  interface  node,  then  enter  a  after 
all  entries  for  the  first  node. 

•  Repeat  the  preceding  two  steps  for  the  second,  third, 
etc.  alrport/alrspace  interface  nodes. 


The  only  entry  in  card  column  1  is  the  first  data  entry  for  each 
airport.  The  above  data  must  be  provided  for  each  airport  in  the  modeled 
system.  Oakland  airport  data  are  contained  on  cards  324  through  336;  San 
Jose  airport  data  are  contained  on  cards  337-345. 

9.  PROCEDURES 

Cards  346  through  434  contain  data  specifying  the  runway  occupancy  and 
airspace  separation  constraints  among  procedures.  Data  on  cards  147  through 
350  define  the  constraints  that  aircraft  performing  procedure  1  have  on  sub¬ 
sequent  related  procedures.  In  this  case,  procedures  1  through  6  are  related. 
The  data  entries  for  each  procedure  are: 

•  Number  of  the  procedure  (must  begin  in  column  1). 

•  Aircraft  type  number,  followed  by  a 

•  Time  periods  (e.g.,  runway  occupancy  times)  in  seconds  during 
which  related  procedure  may  not  be  executed  after  the  given 
procedure  is  executed  by  the  designated  type  of  aircraft. 

9  Minimum  airspace  distances  from  an  airport,  beyond  which  an 
aircraft  of  the  specified  type  executing  the  given  procedure 
must  be  for  there  to  be  no  conflict  with  each  related  procedure. 

ii.  ii 

•  )  • 

•  Repeat  all  but  the  first  entry  for  each  of  the  other  aircraft 
types.  No  data  entry,  except  the  first  for  each  procedure 
should  appear  in  column  1. 

METERING 

The  data  on  cards  435  through  462  specify  where  Level  II  control 
actions  are  to  be  applicable.  The  data  consist  of  specifying  "POST”  nodes 
and  the  associated  "METER"  nodes.  The  data  for  the  first  POST /METER 
systems  are  contained  on  cards  436-439.  The  data  entries  in  order  are: 

e  Number  of  the  POST  node  (must  begin  in  column  1) 

e  Level  II  strategy  to  be  used  (only  strategy  1  is 
implemented) . 


•  Number  of  the  associated  METER  node,  followed  by  a  list  of 
route  numbers  on  which  traffic  passing  through  this  node  is 
subject  to  Level  II  control  actions,  followed  by  a 

•  Repeat  above  entry  for  each  associated  METER  node. 

11.  FLOWS 

The  data  on  cards  463  through  495  specify  where  Level  III  control 
actions  are  to  be  taken.  The  data  entry  on  card  463  after  the  "FLOWS" 
keyword  is  the  time  interval  in  hours  between  Level  III  updates.  The 
remaining  data  consists  of  specifying  "FLOWPOST"  nodes  and  associated 
"FLOWMETER"  nodes.  Data  for  the  first  FLOWPOST/FLOWMETER  system  are  contained 
on  cards  404  through  467.  The  data  entries  are: 

•  Node  number  of  the  FLOWPOST  node  (must  begin  in  column  1). 

•  Average  speed  in  knots  for  traffic  passing  through  the 
FLOWPOST  node. 

•  Node  number  of  che  first  associated  FLOWMETER  node. 

•  Average  speed  in  knots  for  traffic  passing  through  this 
FLOWMETER  node. 

•  Distance  increment  in  miles  for  in-trail  separation  settings. 

•  Round-off  flag 

— 1  if  distance  settings  are  to  be  rounded  to  the  nearest 
lower  increment 

—0  if  distance  settings  are  to  be  rounded  to  the  nearest 
increment . 

•  Minimum  in-trail  separation  distance  setting  for  this  FLOWMETER 
node . 

•  Maximum  in-trail  separation  distance  setting  for  this  FLOWMETER 
node. 

•  List  of  routes  passing  through  this  FLOWMETER  node  for  which  Level  III 
control  is  applicable,  followed  by  a 

•  Repeat  all  data  entries,  except  the  first  two,  for  each  associa¬ 
ted  FLOWMETER  node. 

12 .  TIMING 

The  data  entries  contained  on  card  497  are; 

o  Time  in  hours  when  the  simulation  is  to  be  terminated. 


•  Time  in  hours  ac  which  Che  seed  period  ends. 

•  Time  in  hours  when  Che  firsc  periodic  simulacion  reporc  is 
co  be  printed. 

•  Time  in  hours  between  periodic  simulation  reports. 

13.  MULTDEP 

The  data  on  cards  499  through  513  specify  external  events  for  genera¬ 
ting  aircraft  departure  requests.  The  entries  on  each  of  these  event  cards 
are: 

•  MULTDEP  (must  begin  in  column  1) . 

•  Time  in  hours  when  the  event  is  to  occur. 

•  Route  number. 

•  Aircraft  type  number. 

•  Number  of  aircraft  requesting  departure. 

•  Time  interval  in  hours  over  which  the  departure  requests  are  to 
be  randomly  distributed  (using  a  uniform  distribution) ;  the 
departure  requests  being  for  the  aircraft  type  and  route  given. 


14.  MULTARR 

The  data  on  cards  514  through  531  specify  external  events  for  genera¬ 
ting  aircraft  arrivals  into  the  modeled  airports.  The  entries  for  each 
of  these  events  are  analogous  to  those  for  the  MULTDEP  event.  The  only 
difference  is  that  an  additional  entry  is  required  immediately  before  the 
entry.  This  entry  defines  the  probability  distribution  of  arrival 
times;  a  one  is  entered  for  the  uniform  distribution. 

E.  Setting  the  Airport  Plan  and  Wind  Conditions 

As  mentioned  earlier,  the  above  data  include  the  data  required  to 
exercise  all  four  airport  plans:  the  only  additions  needed  to  define 


the  case  are  PLAN  and  WIND  event  cards  between  cards  498  and  499. 


Entries  contained  on  a  PLAN  event  card  are: 


•  PLAN  (beginning  in  column  1) . 

•  Time  in  hours  when  this  plan  change  event  is  to  occur. 

•  New  plan  number. 

•  Time  period  in  hours  after  this  plan  change  before  departure 
can  resume. 

•  Arrival  clear  flag 

1 — if  departures  under  the  new  plan  are  to  be  held  until 
all  pending  arrivals  which  cannot  transition  to  the  new 
airport  plan  have  landed. 

0 — if  the  above  constraint  is  not  applicable. 

Entries  contained  on  a  WIND  event  card  are: 

•  WIND  (beginning  in  column  1) . 

•  Time  in  hours  when  this  WIND  event  is  to  occur. 

•  Windset  number  where  the  wind  conditions  are  to  be  set. 

•  Direction  from  which  the  wind  is  coming  in  degrees. 

•  Speed  of  the  wind  in  knots. 


The  cards  that  need  to  be  inserted  between  cards  498  and  499  for  the 


various  cases  are  tabulated  below 

WEST  PLAN  VFR 

WIND  0.0  1 

WEST  PLAN  IFR 

WIND  0.0  1 

PLAN  0.0  2 

SE  PLAN  VFR 

WIND  0.0  1 

PLAN  0.0  3 


all  links  are  in  windset  1  by  default) 


270  15  * 

270  15  * 

0.0  0  * 

180  15  * 

0.0  0  * 
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